search

d0ugal / python-rfxcom

A Python 3.3+ library for working with your RFXTrx and automating your home.
BSD 3-Clause "New" or "Revised" License
8 stars 9 forks source link

Refactor Transport and Protocols in an asyncio fashion #17

Open kalfa opened 10 years ago

kalfa commented 10 years ago

See also this comment on issue #16 for a reason to refactor.

In general hardwiring the protocol into the transport is not healthy for testing and reusability. Also it makes harder to extend the module.

Ideally there should be a transport, which does the buffered I/O to the serial port, and either many sub transports with a protocol each, or the serial transport talking to a meta protocol which represents and talks with all the sub protocols.

serial transport 1<-->N protocol transport 1<-->1 specific protocol or serial transport 1<-->1 meta protocol 1<-->N specific protocol

probably, rethinking of what I wrote in the comment, I prefer the latter scenario above.

I'm tempted to say that instead of protocols we should have at the far end of the pipeline "devices instances" (e.g. "dimmer on the right of the sofa", "living room thermostat", "electricity meter"). In this context I suppose that a device is a protocol instance with a specific label. The important bit is that the protocol/device knows how to collect (raw) data about itself. it's not the dashboard which does it (but it can instruct the device on how to collect/aggregate data for instance, or how to publish it).

This is just to split down the chain of responsibility to a finer degree. I still have to check how 'home' does things, to be honest, it might be already like it :smile:

d0ugal commented 10 years ago

This sounds good, I'd love to see the implementation ;).

Home doesn't really handle this, but remember that project is really a proof of concept/experimentation area. I'll add an issue later there with my ideas for refactoring it, hopefully it will fit in with your thoughts. First I'm trying to solve a bigger issue :wink:

kalfa commented 10 years ago

I know, that why I'm writing things :)

I just find hard to think in a non scalable way. Envisioning things needs a perspective :) Writing things "the right way" (whatever it is) helps people to approach the project and help out.

Also, I'm working on a async refactoring of bluepy for the BLE counterpart of this module and I'm encountering the same problems, so I'm just writing my thoughts here for the records.

Luckily, BLE is a Point-to-point protocol and a transport+protocol for each device is enough. rfxcom is a bit more complicated. When there are multiple projects (home, this, bluepy.async) involved it becomes important to try to see where the project can go and try to drive it to this direction when amending/adding features. Still being in the PoC/experimentation area :smile:

I like to experiment with Object oriented design as well as with pragmatica stuff. It's just me.