On Dec 18, 2013, at 11:08 PM, Antoine Pitrou <solip...@pitrou.net> wrote:
> On Wed, 18 Dec 2013 20:02:48 -0800
> Glyph <gl...@twistedmatrix.com> wrote:
>> On Dec 18, 2013, at 5:43 AM, Antoine Pitrou <solip...@pitrou.net> wrote:
>>
>>>> If you need to do something in connection_lost anyway, then why not just
>>>> call create_connection again yourself?
>>>
>>> Because you don't know the connection parameters from inside the
>>> protocol. It's irrational to ask the protocol to know about the
>>> connection parameters when the whole point of protocols is to be
>>> decoupled from transport and connection characteristics.
>>
>> But, as you've said, the protocol needs to examine the reasons for
>> disconnection anyway, and different disconnection reasons may result in
>> different connection parameters. And as I explained previously, even if you
>> have *some* information about your current transport, there's information
>> about how to re-create that transport ("connection parameters", as you say)
>> which can vary by protocol even if the transport itself remembers everything.
>
> Uh, no. The protocol needs to decide *whether* to reconnect, it
> certainly shouldn't know *how* to reconnect (other than say
> `self.transport.reconnect()`). Otherwise the protocol / transport
> abstraction barrier is broken.
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.
However, I guess you're not buying my previous argument about TCP or SSH
reconnection though, so let's talk about something entirely different, not
based on the same substrate :).
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.
Re-establishing the connection may well mean waiting for a USB hotplug event to
tell you that a *new* serial device is available, and at that point you still
have to figure out if it's the right kind somehow. So unlike with TCP where it
means one of N ambiguous things, in this case it means *zero* things unless you
have additional application-specific logic for auditing metadata about
available serial devices.
Is that a more compelling example?
-glyph
