On 01:09 pm, p.may...@imperial.ac.uk wrote:
On 18/07/13 13:10, exar...@twistedmatrix.com wrote:
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?
No-one "likes" it, but if you need to set a socket option, you don't
really have much choice (absent a higher-layer API).
Glad to hear it is universally reviled. ;)
To be a bit more explicit, I think it's worth considering particular
socket options individually and introducing high-level APIs for dealing
with them. They don't get requested too often, so even though it's kind
of labor intensive it still might not be overwhelming.
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.
Well, exactly. It's currently easier for me to sub-class a Twisted
internal/private class. But if that goes away, that option is
unavailable and a replacement would be nice - even if it's a
convenience API like:
connectExistingSocket(...)
Isn't there code to do this as part of the systemd activation?
I really wanted to suggest something along those lines. The current
code has the limitation that it will only accept an *already* connected
socket. There isn't something that will accept a socket and then do the
connection part for you.
Maybe `connectExistingSocket` could still leverage this code somehow to
simplify its implementation, though.
Jean-Paul
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
