On Mon, Jun 7, 2010 at 12:38 PM, Glyph Lefkowitz
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/