[Twisted-Python] improving foolscap's use of Twisted

exarkun at twistedmatrix.com exarkun at twistedmatrix.com
Sat Mar 8 05:52:58 MST 2014


On 10:02 am, dstainton415 at gmail.com wrote:
>
>
>Greetings,
>
>My goal is to get Brian Warner's foolscap library ported to Twisted
>endpoints instead of the older Twisted api interfaces it currently
>uses (ClientFactory and IConnector).
>
>This effort has been documented in foolscap trac ticket #203:
>http://foolscap.lothar.com/trac/ticket/203
>
>and also part of Tahoe-LAFS trac ticket #517 - make tahoe Tor- and I2P- 
>friendly:
>https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517
>
>My question is this:
>
>Since Foolscap's TubConnectorClientFactory does rely
>on clientConnectionFailed... What is the equivalent to this for the new
>interfaces?
>
>I have tried to braindump all my foolscap twisted endpoint thoughts to
>foolscap trac ticket #203 :
>http://foolscap.lothar.com/trac/ticket/203#comment:30
>http://foolscap.lothar.com/trac/ticket/203#comment:31
>
>If we look at line 1223 of
>https://github.com/warner/foolscap/blob/master/foolscap/negotiate.py
>(at 0395476c7cb154f925d67abf6858a8200126352b)
>
>we see that there's this TubConnectorClientFactory:
>class TubConnectorClientFactory(protocol.ClientFactory, object):
>
>and later at line 1384 it is used with connectTCP like this:
>            f = TubConnectorClientFactory(self, host, lp)
>            c = reactor.connectTCP(host, port, f)

It looks like TubConnector is the primary intended user of 
TubConnectorClientFactory.  In this case, you can simply move the logic 
from TubConnector.clientConnectionFailed to an errback on the Deferred 
returned by IStreamClientEndpoint.connect.  Or you can leave it where it 
is an just make clientConnectionFailed be that errback.

For example:

    f = TubConnectorClientFactory(self, host, lp)
    d = endpoint.connect(f)
    d.addErrback(self.clientConnectionFailed)

(removing the connector argument from clientConnectionFailed, of 
course).

You may want to apply a similar transformation to the *success* case 
here as well.  That is, move the code that initiates protocol actions on 
the connection to a callback on this Deferred instead of automatically 
starting those actions in buildProtocol (this gives greater flexibility 
in how the protocol is used - if you want to change the details of 
initialization you can do so by using a different callback on the 
endpoint's Deferred instead of having to mess around with the factory or 
the protocol to disable this stuff).

Jean-Paul




More information about the Twisted-Python mailing list