On Jan 4, 2014, at 11:46 PM, Guido van Rossum <[email protected]> wrote:
> This is similar to the URL-ish syntax I've seen in database drivers > for specifying the database server. Yeah, it's the same principle. > I suppose we could support the > Twisted syntax (if it's documented well enough) or make up our own, > possibly borrowing from URLs (which are another variant of the same > idea). Twisted's syntax is actually pretty bad; the mere fact of the syntax is a great idea but I'd suggest only looking at the particulars of the syntax itself to learn from its mistakes :-). The syntax is 'endpoint-type:positional1:pos2:keyword1=kwval1:keyword2=kwval2'. The problem with this is of course colons are pretty popular thing that you need to be able to type in e.g. IPv6 address literals and win32 paths, so lots of endpoint types require escaping; 'tcp6:\:\:1' is how you say 'localhost' for example. >>> A concrete question: what APIs are missing in asyncio's datagram >>> transport and protocol classes to support SCTP and WebSocket? (Apart > >> DatagramProtocol.datagram_received and DatagramTransport.sendto take an >> `addr` parameter. >> >> However, SCTP and WebSocket are _connected_ protocols. > > On UNIX, UDP can also be connected, and Tulip supports this. :-) "connected UDP" is a strange beast, and it doesn't make UDP a connected protocol; there's still no connection state machine, no way to tell if a particular session is connected or disconnected. >> FWIW: https://twistedmatrix.com/documents/current/core/howto/udp.html#auto3 >> >> Finally: yes, syntactically, there is nothing which would distinguish an >> ordered, reliable datagram interface from and unordered, unreliable datagram >> interface (at least a connected one). >> >> Mmh, but shouldn't the interface _identity_ also express semantics? > > That seems an idea from Twisted. I don't want to go that way. I prefer > giving the transport object an inquiry method if necessary; that's how > asyncio does it for the capability to use write_eof() (which works for > TCP but not for SSL/TLS). The principle that we use type-names to identify discrete sets of behavior is an ideal that Twisted strives to adhere to, but it seems like a pretty basic idea about type systems, not an idea we came up with. ("We use types for nouns" in the words of Nathaniel Manista & Augie Fackler, both of whom are very much not associated with Twisted ;-).) It's just having a consistent way to talk about sets of methods and attributes and stuff. Isn't this the whole reason that ABCMeta.register exists, so you can use ABCs in this way? Then the inquiry method is always consistent, 'isinstance'. >> If I get a transport, and want to adjust behavior according to whether the >> transport is unreliable, even today I am not supposed to do that >> via isinstance(transport, DatagramTransport), since DatagramTransport >> doesn't imply any semantics, but only specifies a programmatic interface (on >> a syntactical level)? > > You're already writing your protocol code specific to either a > datagram or a stream transport, because the protocol API is > (intentionally) different. So there's never a question about which > kind of transport you have. I think that the point that Tobias was trying to make here is that if you have some generic string-syntax way of generating a transport (like endpoints) and the user can enter any transport-type they want, how does an application say "I am only going to work over a reliable+ordered transport". In Twisted (and in Zope) there's a pattern of using a zope Interface or a python type object to identify the required semantics (as he pointed out above). In the case of endpoints, we just don't have any interfaces for datagram endpoints yet, since those are pretty esoteric and the only other use-case besides UDP we can come up with is DTLS (which, due to session-management issues, is also esoteric enough to require other setup). -glyph
