[Twisted-Python] Integrating Twisted with ZeroMQ

Christopher Armstrong radix at twistedmatrix.com
Mon Jun 7 18:07:00 EDT 2010


On Mon, Jun 7, 2010 at 12:38 PM, Glyph Lefkowitz
<glyph at twistedmatrix.com> wrote:
> While the endpoints APIs are great and everyone should use them, I think
> it's putting it a bit strongly to say that listenTCP and friends will be
> deprecated.  Reactors are still pluggable, and we'll need a mechanism for
> endpoints and reactors to communicate.  There may be some evolution of those
> APIs in the long term (in particular, the way that connectTCP interacts with
> client factories is slightly weird) but I think that there will always be
> something lower-level than endpoints that is still a public, supported API.
> You just won't be encouraged to use that API at the *application* layer,
> because endpoints are more flexible.

But will that "lower-level than endpoints" API need to be TCP-specific?

We don't have a listenSerialPort, so why do we need listenTCP (by the
way, we should totally have a SerialPortEndpoint)? I understand your
point that some reactors provide addReader while others provide
addOverlappedIOObject (or whatever the heck it's called), but an
Endpoints implementation can DTRT based on the interfaces that the
supplied reactor provides, so I don't see why TCPServerEndpoint can't
just instantiate a port and call addReader/addWriter or the
IOCPreactor equivalent. And maybe we need a better way to deal with
the differences between those reactors, but I don't see why that
requires us to have public transport-specific methods on the reactor.

However, of course I'm not advocating we jump the gun on deprecating
listenTCP and so forth. We shouldn't deprecate them now, and when we
do, we should make it an *extremely* long period of PendingDeprecation
followed by Deprecation.

-- 
Christopher Armstrong
http://radix.twistedmatrix.com/
http://planet-if.com/



More information about the Twisted-Python mailing list