[Twisted-Python] Error (and response) handling in protocols

[Jason Heeris]

On 21 February 2011 16:59, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
> I'm a little confused as to why this is a connectionless protocol, if
> it's talking on a serial port? Surely it's a singleton connection, with
> no connect/disconnect events?

There's a connectionMade event when you do SerialPort(protocol, ...).
There's no connectionLost event, even if you do that over and over
again.

> I know next to nothing about using Twisted for serial, but why aren't
> you using a single long-lived protocol instance?

Should I? I don't know. My problem is, as a newbie, I *just don't
know* what the usual way to approach a problem like this is. Or if
there is one.

So, please help me think this through... let's say I have this
long-lasting protocol. It needs to keep a DeferredLock, so it doesn't
try to send one message before it's received the reply for another —
right? It should have a method for sending a command that returns a
Deferred, that will eventually fire with the response (parsed and
converted as necessary, that bit's easy). The bit I have trouble with
is that the *origin* of the Deferred callback or errback is the
"lineReceived" method — somehow this method needs to know which
Deferred to callback with the response. But how?

Here's a sketch:

    class CommandProtocol(LineReceiver, TimeoutMixin):

        def __init__(self):
            self.lock = DeferredLock()

        def _runCommand(self, command):
            message = self.constructMessage(command)
            self.sendLine(message)

        def runCommand(self, command):
            d = self.lock.run(self._runCommand, command)
            d.addCallback(command.parseResponse)
            return d

Where does the bit go that fires the Deferred? Should I set it in
_runCommand somehow? I just can't seem to picture it.

Thanks,
Jason

PS. Twisted has great documentation for its individual components, but
as soon as you get into anything that doesn't centre around
"reactor.connectTCP", it seems like you're in the dark. All of the
examples and tutorials seem to have near-trivial, completely
synchronous protocols, requiring no back-and-forth or error handling.
Ultimately I'd like to take all of this advice, have an epiphany,
finish my project, bundle my new-found wisdom up into a neat little
package of things I think would make serial comms a happier experience
for all, and publish it somewhere. And maybe write about how to use
Twisted for non-internetty things. But I do need to actually
accomplish something first.