The Autobahn guys still show ReconnectingClientFactory in their docs,
Where did you find that? That would be a doc bug, but in the _docs_, there is no reference to ReconnectingClientFactory (cpy372_3) oberstet@intel-nuci7:~$ find ~/scm/crossbario/autobahn-python/docs/ -type f -exec grep -Hi "ReconnectingClientFactory" {} \; (cpy372_3) oberstet@intel-nuci7:~$ We do have some example code using ReconnectingClientFactory though: (cpy372_3) oberstet@intel-nuci7:~$ find ~/scm/crossbario/autobahn-python/examples/ -type f -exec grep -Hi "ReconnectingClientFactory" {} \; | wc -l 8
and I remember looking at this before and ending up going with ReconnectingClientFactory because it works and didn't look like it'd need much effort to integrated into an existing code base.
Let me count the ways.
1. ReconnectingClientFactory is destined for deprecation, eventually. You should just adopt the "new" thing now so that if we get more energy to cycle the APIs and delete the old stuff, you'll have less hassle to deal with. ("New" is in quotes here since it's been around for well over 3 years at this point; Autobahn should update too, not just you.)
Autobahn will automatically use twisted.application.internet.ClientService for auto-reconnect when on Twisted 16.1.0+ https://github.com/crossbario/autobahn-python/blob/master/autobahn/twisted/w...
2. ClientService works with endpoints, which means you can use it with /any/ kind of transport, like SSH transports, subprocesses, etc. Most practically, it works with HostnameEndpoint which is a much better way to get TLS than connectSSL; ReconnectingClientFactory works, kind of accidentally, with TLS since connectSSL is on the reactor, but it won't use happy eyeballs and it won't connect over IPv6, so connections will be slower and less reliable. 3. Conceptually, ClientService has a much clearer and more useful responsibility: its job is to /maintain a state/ (i.e.: that there is a single connection, that it is connected) rather than to /do a thing/. For example, 1. if you want to shut down a ReconnectingClientFactory: 1. you have to call stopTrying, then uh... 2. find the last protocol it built with buildProtocol, then 3. grab its transport (hope it's saving that transport as '.transport', because it doesn't actually have to) 4. call loseConnection 5. remember to trap connectionLost so you can see when its done. 2. if you want to shut down a ClientService 1. call stopService 2. wait for the Deferred that it returned to fire 4. ClientService is (mostly) implemented using composition rather than inheritance, so much less of the guts of the internal implementation is hanging around where you might accidentally twiddle it and break its assumptions, so you can trust its guarantees more.
++1 (note: Autobahn is a culprit to the overuse of inheritance vs composition too .. but the so-called "new API" (for WAMP) is following composition + observer pattern, while the "old API" (that is inheriting from ApplicationSession) is still pretty much around. we have some legacy already ..)
1. other benefits of composition: you don't have to override attributes of your Protocol and thereby indulge in subclassing yourself to get notifications; consider 'prepareConnection', 'whenConnected'. 2. the retry policy mechanics are better documented and much easier to customize 3. it's backed by a formal state machine - not that I'm aware of any specific bugs in ReconnectingClientFactory but do you think it got /all/ of these state transitions correct: https://gist.github.com/glyph/614be03151556333efe04b849fa05930 5. It's more testable because it just takes its clock and reactor as constructor parameters, rather than requiring post-hoc poorly-documented attribute patching to become testable.
Hopefully at least some of this is convincing :)
all and each of them is convincing;)
-g
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
-- Tobias Oberstein - phone +49 176 2375 2055 - tobias.oberstein@crossbario.com Crossbar.io GmbH - Waldstrasse 18 - 91054 Erlangen HRB 15870 - Amtsgericht Fuerth - Geschäftsfuehrer/CEO - Tobias Oberstein https://crossbar.io https://crossbario.com