Charge Point Refactoring

[tropxy]

Refactored the project to make it clear the separation between creating a central system and a charge point or a charge point handler

[tropxy]

I like the effort to make it more clear that ocpp.v16.ChargePoint can be for on both end of the websocket connection. It can be used to model a charge point at server side, in the central system. But this class can also used to model the client, the charge point.

But I am not sure though if renaming to to ocpp.v16.OcppFactory creates the clarity you seek.

I want to propose a different solution. Let's move the 'ChargePoint' class to 2 namespaces, like this:

ocpp.v16.central_system.ChargePoint ocpp.v16.charge_point.ChargePoint

Or:

ocpp.v16.server.ChargePoint ocpp.v16.client.ChargePoint

I think that creating a class for both both roles makes it more clear that you can use the this library to model a charge point on both ends of the websocket connection.

This split into 2 classes also has an other future benefit. . We can implement validation to prevent messages being send 'in the wrong direction'. Except from DataTransfer, all other OCPP messages can only be send from client to server, or only from server to client.

For example we could prevent a ocpp.v16.central_system.ChargePoint to send a BootNotification.

What do you think?

I think you are right and I like your suggestion of creating 2 namespaces. However, I still dont like we call it ChargePoint in both ends, but tbh, I am not sure if there is a perfect solution for this problem. Let us discuss this tomorrow or whenever we both have time and see if we can come up with a good idea to solve this.

[jchinnick-nuvation]

Also, please consider that the Local Controller will act as both a client and a server with one or more handlers for local charge points.

Perhaps ocpp.v16.ChargePointHandler and ocpp.v16.ChargePoint would serve as reasonable class names.

[OrangeTux]

@jchinnick-nuvation Thanks for your suggestion. I like the the suggestion of ChargePointHandler and ChargePoint.

Do you think it makes sense to put ChargePointHandler and ChargePoint in there own namespace to make the distinction between the classes even more clear? So ocpp.v16.server.ChargePointHandler and ocpp.v16.client.ChargePoint

@tropxy What do you think?

[jchinnick-nuvation]

@tropxy Adding in the server/client namespaces does make sense, especially if there will be other elements of the interface that are distinct between the two use cases.

[tropxy]

@jchinnick-nuvation Thanks for your suggestion. I like the the suggestion of ChargePointHandler and ChargePoint.

Do you think it makes sense to put ChargePointHandler and ChargePoint in there own namespace to make the distinction between the classes even more clear? So ocpp.v16.server.ChargePointHandler and ocpp.v16.client.ChargePoint

@tropxy What do you think?

Yup, I like it! This PR had the ChargePointHandler and ChargePoint distinctions, but I think it will be clearer if we combine it with distinct namespaces. If you also agree, Auke, I will asap open a PR with it. Thanks @OrangeTux and @jchinnick-nuvation for your suggestions!

[OrangeTux]

Closed due inactivity.