On 10:27 am, p.may...@imperial.ac.uk wrote:
On 17/07/13 18:44, Glyph wrote:
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.
Agreed. But then, it's been a couple days and nobody else has
contributed to this thread :-).
Well, since I started it...
Some kind of endpoint argument might be problematic for some use-cases.
In particular, Twisted would have to know how to convert the argument
into the value to pass into setsockopt() and possibly in a platform-
specific way.
The API as presented also omits the SOL.
It wasn't so much an API as a "Hey, I have an idea... endpoints... here
is an example I can think of in 10 seconds." :)
I guess it might be ok if there was a way to reliably inject unknown
options with arbitrary payloads, but I'm struggling to see a clean way
to do this with a "parse a string"-style API.
I think you're talking about the fact that "sockopts" are random
integers associated with other big piles of random integers. Some of
them are flags you turn on, but some come with random payloads of
basically no possible known shape.
It sounds like you're trying to think of an API that will support any
and all socket options without understanding them. This API exists
already. It is `setsockopt`. There's no reason to re-invent it.
I prefer the approach taken elsewhere in Twisted, where a particular
option is given some consideration and an API that understands the
option is introduced. This approach certainly has its shortcomings -
for example, it doesn't support arbitrary options. :) Do people really
like using `setsockopt` though?
So, vote me +0.5 for a "pre-connect" function.
But but but...
It might be possible to sidestep this entire issue by providing a clean
way for an app to inject itself "above" the socket. I can think of a
few use- cases for this, most notably things like cmsg/IP_HDRINCL which
Twisted doesn't know about, and thus can't handle.
So maybe the correct way to handle this is "implement your own FD
object"?
Nothing stops anyone from doing this already, today. Except that it's a
lot of work and no one seems to want any of these features badly enough
to do it.
Jean-Paul
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
