On 01:01 am, gl...@twistedmatrix.com wrote:
On Jul 12, 2013, at 5:09 AM, exar...@twistedmatrix.com wrote:
On 10:42 am, p.may...@imperial.ac.uk wrote:
On 12/07/13 11:34, Itamar Turner-Trauring wrote:
Subclass twisted.internet.tcp.Client, override
createInternetSocket() so
it calls setsockopt() on the socket after you've called base
implementation to create it. This breaks some abstraction
boundaries, so
it isn't great, but very little code duplication is involved.
Ah, ok. Presumably I also need to subclass Connector and override
_makeTransport to use MyClient, then call MyConnector() directly (or
subclass the reactor... shudder)
Should there be something built in to Twisted for this? Should I open
a ticket?
If you want your code to keep working, or to work with alternate
reactor implementations, then you'd *really* rather use a documented,
tested interface rather than the hack outlined above.
Does such an API exist today, or should a ticket be filed for one?
Hm, I'm not *totally* sure what you mean.
There's the approach Itamar outlined, using APIs such as
`twisted.internet.tcp.{Client,Server}`. I don't think we should codify
this as the public, stable, encouraged API to use - for precisely the
reasons you give below.
There's various other APIs that are clearly related but definitely don't
currently allow you to wedge this functionality in:
1) reactor.connectTCP - nowhere to pass extra socket options now, but
we could add more arguments to it I suppose. Doesn't sound very nice to
me.
2) endpoints? Again, no current support, but it's a place you could
add new parameters. Of course, this isn't a complete solution, since
endpoints mostly just use reactor methods to set things up - but if we
had a nice endpoints-based API then we could have a gross lower-level
API that no one actually has to use. Still, is
"tcp:host=A:port=B:sockopt=TCP_CORK|TCP_QUICKACK" the road we want to go
down?
3) More transport methods - but this is an incomplete solution, as
certain sockopts only make sense before a connection, so once you have a
transport it's too late.
Maybe someone else has some suggestions from a totally different
ballpark that solve the problem more pleasantly?
Anyhow, I think this certainly means a ticket should be filed for
introducing some API - but it seems that a little more discussion about
what the API should be will still be necessary.
Jean-Paul
For everyone's information, in case it's not entirely clear from the
documentation resources available: we hope to eventually deprecate the
whole 'tcp' module so that people (myself included ;-)) stop
subclassing stuff in it, so writing new code that depends on this, even
the nominally "public" parts of the API (the bits without underscores)
would be really unfortunate. If we can figure out something that uses
totally public APIs without subclassing tcp.Client that would be best;
if not, we should really have a ticket open to fix the API so that it
is possible.
-glyph
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
