ocpp library as an event based message handler #168

[villekr]

Work in progress related to issue #168.

This change adds a new Router base class that contains message routing functionality and modifies it to allow stateless and event based message handling. ChargePoint inherits this new base class and works unchanged providing a way to implement stateful bundled (i.e. both action handlers and websocket connection must be within ChargePoint class) message handler.

A new Router subclass in asgi_routing.py implements ASGI interface and enables decoupling action handlers from websocket connection.

[OrangeTux]

Thanks for your effort! By using type hints and creating interfaces you made this PR easy to read. Also the examples are helpful to express your ideas. IMHO this PR is much better in transferring your ideas than work in https://github.com/villekr/ocpp-serverless-example.

I'm still trying to understand everything, but I can already share some first thoughts.

I'm not sure if I like the stateless example. For two reasons. First the handler is not stateless as it receives a reference to the ChargePoint instance via self. Second the signature of the method decorated by @on() changes completely. The @on() decorator can now be used on 2 total different types. I think that would be very confusing for users of this library. Support for stateless routing should be more explicit.

I'm also not sure about adding an optional Context attribute to all several of the method on Router like route_message() and call(). I'm not sure if we should 'pollute' the API that works for most use case with arguments to support a rather specific use case. Maybe this can be avoided by creating a subclass of Router and add these modification. While leaving the current implementation (nearly) untouched.

Although it sometimes takes some time before I respond I really appreciate your effort!

[villekr]

Thanks for checking out and giving feedback for this work in progress version. For stateless routing I think it's unavoidable that @on() and @after() signatures have to be changed as compared to current ones and that's of course unfortunate. In stateless example ChargePoint instance is not involved but Router base class is, which has still few member attributes defined. So in that sense yes, it's not as stateless as I'd like it to be.

This draft manages to maintain backwards compatibility both for ASGI stateful and ChargePoint usage. However, it hangs on how ChargePoint is implemented. So in many ways it would propably lead to more understandable interface to just break backwards compatibility when using ASGI interface and keep ChargePoint usage as is.