CODEWITHSUNDEEP
pythonprotocolstwistedcomplexity-theory
Mark Moissette
Mark Moissette

Reputation: 169

Custom Python Twisted protocol : good practices and complexity?

I am currently working on a control system for Arduino type devices using Twisted,and have a bit of a design issue

Here is how things are currently: (sorry in advance, might be a bit long)

  1. to handle different type of devices (each having a different firmware & communication protocol ) i have a designed a "driver" system :
    • each driver is made of :
      • a "hardware handler class" : a wrapper around Twsited's serial class with a few added helper methods
      • a custom serial protocol

2- While implementing drivers for Reprap 3d printers (also based on arduino, also using a serial connection) with rather specific protocols (ie enqueue point, set temperature etc), i have started to wonder if i am placing the methods for handling those features (each having specific commands) in the right place..

This all leads me to my questions:

I am not quite sure about the good practices as far as twisted protocols go , but having looked through the documentation / code of quite a few of them, it seems they tend to have relatively few methods

Any advice, tips and pointers are more than welcome ! Thanks in advance.

Upvotes: 2

Views: 2229

Answers (1)

oberstet
oberstet

Reputation: 22011

I'll try my best at answering a, well, quite general question.

1) The interface that make up a Twisted protocol has only 4 methods: http://twistedmatrix.com/documents/11.0.0/api/twisted.internet.interfaces.IProtocol.html So this will be where all the interaction between your protocol implementations and Twisted happens.

2) Besides instances of protocol, there is of course the factory which produces instances of your protocol (for each new connection). So for example, stuff that should be available to all connections (like i.e. current number of connected clients, whatever) naturally resides there.

3) Of course it might make sense to build small class hierarchies, where you derive from Protocol, implement stuff that is shared by all your subprotocols, and then only implement the subprotocol specifics again in a derived class.

Upvotes: 3

Related Questions