[Twisted-Python] Proposal: changes to reactor.clientTCP

[Glyph Lefkowitz]

From: Ivo van der Wijk <ivo at amaze.nl>
Subject: Re: [Twisted-Python] Proposal: changes to reactor.clientTCP
Date: Sun, 16 Jun 2002 01:06:51 +0200

> On Sat, Jun 15, 2002 at 06:04:29PM +0200, Itamar Shtull-Trauring wrote:
> > Background:
> > Ivo pointed out there's no way to differentiate between "no such 
> > hostname" and "connection refused". For that matter, connectionFailed 
> > has nothing to do with the protocol - why are we doing a callback on the 
> > protocol at all? It shouldn't be created if no connection was made.
> > 
> > Proposal:
> > reactor.clientTCP accepts a protocol factory instead of a protocol, and 
> > only makes a protocol instance if connection was made. Additionally, it 
> > accepts an additional argument, failureCallback, which will get called 
> > with a status code (CONNECTION_REFUSED, NO_SUCH_HOSTNAME) or something 
> > when the connection fails. Protocol.connectionFailed goes bye-bye.

You know, I'm tempted to disagree with this because backwards-compatibility at
this point is a really major argument to me at this point ... however, you guys
make some really good arguments.  It may even be possible, given this
description, to make __init__, and not makeConnection, be the real
"initializer" of a Protocol at this point.

The inability to report these errors has also been an annoyance on the
client-interface end of things for some time.  There is an asymmetry between
client and server-side connecting in IReactorTCP.

In addition, Itamar's proposal would simultaneously eliminate the confusion
currently surrounding Connectors, too; having a wrapper protocol *factory*
would not pose the same efficiency concerns as a wrapper Protocol instance,
since indirection would only happen when opening and closing the connection.  

> > Comments?
> 
> Some people don't see a point in providing these errors, so I'll illustrate
> the issue with some more examples:

Also, being able to report these errors is important to judge at what level
networking is misconfigured for the end-user, when they can't connect.

> I agree with itamar that if these errors aren't handled in the protocol
> implementation, failure to connect shouldn't be there either.

After hearing this, so do I.  Thank you for the bug report.

-- 
 |    <`'>    |  Glyph Lefkowitz: Traveling Sorcerer  |
 |   < _/ >   |  Lead Developer,  the Twisted project  |
 |  < ___/ >  |      http://www.twistedmatrix.com      |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20020615/96515692/attachment.pgp