[Twisted-Python] Using SerialPort with t.a.s.Application

[exarkun at twistedmatrix.com]

On 03:50 pm, albert.brandl at weiermayer.com wrote:
>Hi!
>
>I'm quite happy that my question (or really: Itamar's answer) triggered
>the interesting discussion about glossaries. But there are some aspects
>about SerialPort that are not yet clear to me. So I'm trying to reclaim
>this thread ;-).
>
>On Fri, Jan 28, 2011 at 08:25:52AM -0500, Itamar Turner-Trauring wrote:
>>The TCP port doesn't implement IService either...
>
>This is correct. But TCPServer does implement IService, and I was
>looking for an analog I could use for the serial port. I'd like to 
>write
>something along the following lines:
>
>def setupSerialCommunication(multiService):
>    lrFactory = MyLineReceiverFactory()
>    serialComm = internet.SerialServer(lrFactory, '/dev/ttyS0')
>    serialComm.setServiceParent(multiService)
>
>(BTW: I'm not quite sure if SerialServer would belong to the internet
>package...)
>
>In my understanding, the communication over the serial line should be
>handled in a similar way to communicating via TCP/IP. So my questions
>should have been: Why isn't there an analog to TCPServer for 
>SerialPort?
>Would it make sense to add it?

I think that now the way it would make sense to add this is to add a 
serialport endpoint.  This would be usable with 
twisted.internet.endpoints.serverFromEndpoint (or clientFromEndpoint, I 
can never remember which one a serial port is more like).

Then, this endpoint could be combined with a general-purpose endpoint- 
into-service adapter.
>>A service is supposed to be something you can start and stop, and
>>encapsulates a self-contained piece of business logic. The purpose is
>>both deployment and ease of regression testing.
>
>Thanks for the explanation. It is certainly a good idea to think about
>the partitioning of the services and reflect it in the code.
>>So maybe your service starts both a webserver and a serialport,
>>because it requires both -- which is why mostly you should just
>>implement your own service classes.
>
>There is the class t.a.s.MultiService for encapsulating other services.
>In my current implementation I just instantiate it and add the other
>services; afterwards I set its service Parent to the application. What
>would be the advantage of subclassing Service and redefining its
>startService and stopService methods?

If you can accomplish your goals without making a new kind of IService 
implementation, then great!  If it is awkward (for example, if you want 
the web server to have a reference to the protocol currently connected 
to the serial port), then it might be easier if you have your own 
IService implementation that knows about both your web server and your 
serial port.

Jean-Paul