albert.brandl at weiermayer.com
Wed Mar 24 08:39:17 EDT 2010
The NetstringReceiver class does not exactly do what I'd expect - see
issue http://twistedmatrix.com/trac/ticket/4378. Since we plan to use
netstrings, I am trying to fix it.
I am not quite sure how to handle certain problems, though, and that's
where I'd appreciate help. If this is the wrong place to ask this kind of
questions, please redirect me ;-).
1.) In the current implementation, a NetstringParseError results in a
call to self.transport.loseConnection(). Furthermore the variable
brokenPeer is set to 1. But this variable is ignored. Would it be better
to check it before receiving data? If yes: what is the correct way for a
protocol to handle a broken transport? There is a ConnectionLost
exception, but I'm not sure if / when a Protocol is allowed to raise it.
2.) The current implementation uses the method dataReceived to assemble
the content of the netstring. When it is complete, the method
stringReceived (which raises a NotImplementedError by default) is called.
But netstrings can be long - would it be better to create a Deferred
instance and call its callback instead? What would be the right place to
create this Deferred?
3.) I started testing the NetstringReceiver by creating a class comment
with doctests. When I later grepped the sources, I found some doctests,
but there no mention of the doctest module in the test policy document.
Would it be better to use the unittest framework for testing the code?
Thanks and best regards,
Weiermayer Solutions GmbH
4813 Altmünster | Abteistraße 12 | Austria
Fon: +43(0)720 70 30 14 | Fax: +43 (0) 7612 88081
More information about the Twisted-Python