Adopt dali.driver.daliserver API according to dali.driver.base

[rnixx]

• Create TCPBackend analog to USBBackend (https://github.com/sde1000/python-dali/blob/master/dali/driver/base.py#L134)
• Create TCPListener analog to USBListener (https://github.com/sde1000/python-dali/blob/master/dali/driver/base.py#L197)
• Create DaliserverDriver (Example https://github.com/sde1000/python-dali/blob/master/dali/driver/tridonic.py#L85)
• Create SyncDaliserverDriver (Example https://github.com/sde1000/python-dali/blob/master/dali/driver/tridonic.py#L211)
• Create AsyncDaliserverDriver (Example https://github.com/sde1000/python-dali/blob/master/dali/driver/tridonic.py#L240)

[mhemeryck]

In #48 you mentioned you could need some help with implementing this. Just curious if you could elaborate a bit more on this. Is this about writing a generic TCP reader / writer to interface with?

And how would that work? Is it about doing some communications using python's sockets? What kind of data (/protocol) would you send over it (the DALI commands themselves)?

[rnixx]

Hi,
the idea would be to implement a TCP (yes python socket) backend with this contract https://github.com/sde1000/python-dali/blob/master/dali/driver/base.py#L97
Also a TCP listener with this contract https://github.com/sde1000/python-dali/blob/master/dali/driver/base.py#L114

further a concrete dalidriver implementation is necessary implementing the communication protocol as described in https://github.com/onitake/daliserver via this contract https://github.com/onitake/daliserver

[mhemeryck]

Sorry for the late reply, only now had the first chance to really look at how the code was structured.

I will probably focus more on #48 for now, since I will be needing that one sooner. While checking up on that, I ran into some questions on how the generic driver interfaces are set up (that, and also that this will probably serve as a mental-note-to-self later on 🙂).

If I understand it correctly, these are more or less the "contracts" that are expected:

1. Backend: communication with physical devices, sending raw data in for that specific device
2. Listener: augmented version of a Backend, also able to listen to that device
3. Driver: able to do translation between DALI commands and raw data frames
4. SyncDriver: send data prepared via driver, to the backend (SyncDriver has a Backend instance)
5. AsyncDriver, send / receive data prepared via driver, to / from listener (AsyncDriver has a LIstener instance)

Some remarks / questions on that:

1. inheritance structure: what was the rationale behind this? I like the fact there are clear contracts like the drivers (construct, extract) and the backends (read, write, close) / listeners, but at the level of the SyncDaliDrivers there seems to be a lot of functionality that is made available via inheritance. As alternatives, you could have:

• the driver contract (construct / extract) is an instance that the SyncDaliDriver uses instead of inheriting it
• the driver contract is just a function that is passed in (although for python, abstract base classes are probably a better way -- the only way to enforce an interface)
• mixins: flatten the inheritance tree by putting the functionality in a set of mixins (one driver could be a mixin)

2. abstract base classes: for abstract base classes (like the Driver), you can also use the python built-in abc to really ensure any implementing class follows that contract

[sde1000]

Not my area of expertise: the SyncDriver and AsyncDriver stuff has all been @rnixx and I haven't used any of that code personally.

I'm concentrating on new asyncio-based drivers for now. I've committed some initial code but the interface is still subject to change: I still need to add support for things like DALI transactions that aren't yet supported in all hardware but are described in the standard.