If you look in the Tulip examples directory there's a reconnecting client for a custom protocol in cacheclt.py.
FWIW I expect that the dynamic creation of protocol classes in Johan's example is wasteful -- a Python class object costs a lot of resources. A plain old un-nested class and a lambda would seem more appropriate. On Thu, Dec 26, 2013 at 4:27 AM, Jonathan Slenders <[email protected]> wrote: > Hi all, > > I implemented auto reconnect for the redis library: > > It happens here: > https://github.com/jonathanslenders/asyncio-redis/blob/master/asyncio_redis/connection.py > > There is a pubsub example now that reconnects successfully: > https://github.com/jonathanslenders/asyncio-redis/tree/master/examples/pubsub > > Cheers, > Jonathan > > > > > Le vendredi 20 décembre 2013 15:58:40 UTC+1, Antoine Pitrou a écrit : >> >> On Fri, 20 Dec 2013 01:06:29 -0800 >> Glyph <[email protected]> wrote: >> > >> > You're right that there should be an abstraction barrier here. In >> > Twisted, the abstraction here is called an "endpoint". However, while this >> > abstraction should not have to be part of every protocol, it is also not >> > part of every transport. A transport is an object that can move some bytes >> > around. "Re-connecting" is not necessarily part of that contract, even for >> > a "client" transport. The fact that TCP client superficially makes it >> > possible to do this is misleading. >> >> This is true, but then reconnect() can simply raise >> NotImplementedError. >> >> > Consider a serial port. You "connect" to a serial transport because >> > control over a serial port is exclusive. However, if the connection is >> > lost >> > (i.e. the serial device is removed) there's no sensible thing for >> > "reconnect" to mean. >> >> Same answer :-) >> >> Regards >> >> Antoine. >> >> > -- --Guido van Rossum (python.org/~guido)
