On Jan 3, 2014, at 2:13 PM, Guido van Rossum <[email protected]> wrote:
> I'm not entirely sure what Twisted endpoints are Endpoints are really very simple. They're two interfaces for listening and connecting; .listen(factory) for servers and .connect(factory) for clients. They each return a Deferred, which fires with an IListeningPort and a connected IProtocol instance, respectively. As the documentation puts it, "there's not a lot to it": <https://twistedmatrix.com/documents/current/core/howto/endpoints.html#auto2> > and why they're so cool. They're cool because they decouple the part of the program which figures out what to listen on or connect to from the part of the program that figures out when to listen or connect. This allows you to transparently support running a protocol over an outbound TCP connection, outbound TLS connection, or something fancier, like an SSH command tunnel. Similarly, since 'listen()' returns a Deferred, you can do asynchronous set-up when your program opens a new listening port (like, for example, executing firewall rules or manipulating a load balancer's configuration). Also, there's the thing that Tobias was referring to, the ability to parse a string into an endpoint. This involves a plug-in interface so that third party packages can add new endpoint types, so you can run things over new types of transports without writing any new code at all (as long as applications use serverFromString or clientFromString to parse their command-line arguments, and an increasing number of the servers built in to Twisted do). > (Glyph kept telling me they were cool but not quite ready or something, so I > never had a good look.) The thing that wasn't ready was <https://twistedmatrix.com/trac/ticket/4859>, which is an example of how to implement the 'happy eyeballs' RFC, in terms of the endpoint API. It's done in the most recent Twisted release :-). As I recall, when I said they weren't quite ready, I was trying to suggest that tulip not even have an API like create_connection, and just have connect() that only took IP addresses, not hostnames, and put the name-resolution bits exclusively into the endpoint, but we hadn't proven that concept yet with Twisted. We still haven't quite, because the "low-level" API that HostnameEndpoint.connect() calls is still connectTCP(), which can in fact take hostnames (although it does something a lot less useful, TCP4 resolution only). > But most of what you describe here should be possible equally well with > asyncio's protocol/transport > abstractions (which are pretty close to those in Twisted, if you > aren't too attached to Deferred). So what's missing?(Probably nothing > that couldn't be added on top of asyncio as a 3rd party package.) Indeed, none of this is terribly complicated. It would be useful to put them into Tulip proper though, even if no functionality beyond what create_connection offers is available, so that application code doesn't use low-level loop interfaces like create_connection and create_server, since those aren't extensible. If applications habitually use this simple little bit of indirection, you can get the same sort of no-new-code flexibility for new transports that Twisted offers, at least at the library-code level. Hope that was useful, -glyph
