Current state of the project

[lilgallon]

Hi there,

The lib got a lot of attention lately, so I would like to share some information with you :)

Context:

This lib was initiated in 2022 by the company Izivia which is a French eMobility company. The project was then deprioritized quite quickly, and there was a long period of inactivity. Recently, Izivia reprioritized the lib, and the goal is to have a "stable" version in mid 2024.

It is getting more and more attention, and there is no contribution guidelines yet (it will come soon), but we will review your PRs with pleasure.

Current state

As of today (2023, 1st of December), only the versions and credentials modules were tested with real partners. The next module will be location. The rest of the module were implemented following the OCPI protocol, but they are not properly tested yet. So you should expect to find a lot of bugs on these modules.

If you use the lib today, you have to expect to get breaking changes in the API in the following months. The overall approach will not change though, so breaking changes should be limited. Version 0.0.15 will bring a lot of changes, and its goal is to include most of the planned breaking changes (using camelCase kotlin code instead of snake_case, rename Platform to Partner and so on). In addition to that, I will update readme / set up a contribution guidelines for the repo to be more welcoming for future contributors. So once 0.0.15 will be released, there should not be any more big breaking changes. I plan on releasing it in 2-3 weeks.

Why should you consider using it / contribute ?

We are in communication with real OCPI partners, which allows us to receive real world feedback on the our lib. Currently, we are only testing the credentials and versions modules with real partners, and we are in the process of developing the location module, which we will soon test with a real partner too. The rest will come in the following months.

---

You can say anything below, this issue has been created to discuss about this library

[andacata]

Hi @lilgallon, thanks for the good job you're doing with this library. I found it very useful for our development, and we'll contribute as much as we can.

We'll start using the library as a SCSP, so eMSP part it's so similar, but maybe in the future we can try to use "sender" and "receiver" as OCPI 2.2.1 is describing the involved parts now.

[xhanin]

@andacata Using Sender and Receiver as mentionned in the spec brings some confusion IMO, because a single party is a Sender of one module and a receiver of another. For instance, a CPO is a Sender of Location, Session, CDR, but a Receiver of Token. I think that brings a lot of confusion for newcomers. But this is only an ocpi lib, so maybe we can just stick to the naming used in the spec.

WDYT?

[andacata]

I was thinking about (e.g.) LocationsEmspServer and LocationsCpoServer. It can be LocationsReceiverServer and LocationsSenderServer.

[atschabu]

Just to throw in an extra opinion ... Using Sender and Receiver feels like the more correct thing to do, but I actually tried refactoring a few things to test the naming, and I have to agree with @xhanin , it does get more confusing ... somehow, (at least in my mind) it is easier to map to known roles like CPO and eMSP, compared to the relative Sender/Receiver ... even though it just feels "more correct" 😆

[atschabu]

@lilgallon are there any plans to add more modules any time soon? If so, will you announce it? Main reason I ask, is to avoid duplicate work, as we had implemented Sessions in parallel, and are now moving to the libs version, and I want to avoid similar work duplication for the Tariffs and CDR modules

[lilgallon]

@atschabu I will make sure to post a message here if we are about to implement / work on a new / existing module at least two weeks in advance. For now we are still working on both the credentials & location module. It takes some time because we are setting everything up in our system to use OCPI and it requires a lot of boostraping, and testing. Once everything will be in place, we will be faster. Moreover, OCPI is not the top priority yet, but it is just a matter of time.

I will give as much information as I can in this discussion :)

[lilgallon]

Our first objective that I can share is that credentials, location & session modules have to be production ready in March 2024

[andacata]

Hi @lilgallon. How is the production ready schedule going?

[lilgallon]

Hi, the partner is late (we should have been in production since start of May) on credentials, location & session. We are ready, they are not.

We are currently working on the rest of the modules. I can not say precisely which modules as I am unsure about the priority now, but it sounds like we will be working on the tokens module very soon. Tariff / cdr should come next, but I am still unsure of when exactly.

In our development workflow, we first build our platform around the OCPI spec, and if something is missing / work, we add it in the OCPI toolkit. We are in the phase where we set up everything to manage OCPI communication with our partners, so there are not a lot of contributions in the ocpi toolkit atm. But once our platform will be completely ready to manage OCPI, we will contribute a lot to add everything that is missing.

To sum up what have been done since December 2023:

• We had to be ready for production in May for cred, location & session. So we contributed to ocpi-toolkit to fix / add stuff
• When we were ready (a few months ago), we started working on our platform to manage properly OCPI communication with our partner (UI to manage everything OCPI-related)

Soon we will be adding support for new modules, and you should see contributions to ocpi-tookit. Don't worry, the project is not abandoned, we are just currently building stuff on top of it ;)

[andacata]

Glad to hear it 🙂

Thanks for all your hard work! 💪