Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CPO & eMSP vs. Sender & Receiver #83

Open
andacata opened this issue Feb 22, 2024 · 1 comment
Open

CPO & eMSP vs. Sender & Receiver #83

andacata opened this issue Feb 22, 2024 · 1 comment
Labels
discussion Further information is requested

Comments

@andacata
Copy link
Contributor

Hello,

I want to start a discussion (again 😄 ) about the use of CPO & eMSP vs. Sender & Receiver.

As an example, I'm currently implementing the ChargingProfiles module which allows different topologies:

  • eMSP <-> CPO
  • SCSP <-> eMSP
  • SCSP <-> CPO

As you can see, the eMSP can act as a Sender or as a Receiver, so naming ChargingProfilesEmspServer will be very confusing.

@lilgallon lilgallon added the discussion Further information is requested label Feb 26, 2024
@lilgallon
Copy link
Member

We started using Emsp and Cpo in class names because that is what is used in the OCPI spec (at least for Location and Session modules). Reading the ChargingProfiles spec, I agree with you, it may be confusing.

Having XXXXSenderServer or XXXXSenderInterface may also be confusing. Taking Locations modules in example, it would give:

  • LocationsCpoClient.kt -> LocationsSenderClient.kt
  • LocationsCpoInterface.kt -> LocationsSenderInterface.kt
  • LocationsCpoServer.kt -> LocationsSenderServer.kt
  • LocationsEmspClient.kt -> LocationsReceiverClient.kt
  • LocationsEmspInterface.kt -> LocationsReceiverInterface.kt
  • LocationsEmspServer.kt -> LocationsReceiverServer.kt

I believe there's room for improvement in our approach to naming, but I'm not entirely certain about the best approach

calling @xhanin's insight

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants