Thanks! That's just what I needed. On Sat, Mar 8, 2014 at 12:52 PM, <exar...@twistedmatrix.com> wrote: > On 10:02 am, dstainton...@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 > > _______________________________________________ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
