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).
Yes, that's the issue I was trying to raise.
How can 2 implementations exposing the same API ("datagram"), but with
different semantics ("unreliable" vs "reliable-ordered") programatically
signal that difference in semantics.
Which I specifically don't like (as I pointed out above :-).
I read between the lines of the Twisted endpoints docs that they don't
support anything besides streams. I suspect that the use case for the
inquiry discussed here is purely theoretical.
Here is my use case: I am working on WAMP, which is a protocol that
provides Publish & Subscribe and RPC over any transport that is:
- reliable, ordered, full-duplex, message-based
WebSocket is one transport. Shared-memory queues is another. SCTP might
be a third.
I want to decouple an implementation of WAMP of the underlying transport
using the "right abstraction".
I believe Tobias actually cares about the actual additional framing and typing
features of WebSockets, which _do_ have different semantics from TCP.
Personally I feel like these features are just dumb over-engineering, and
should be ignored as much as possible. So I'm given to agree with you about
their theoretical nature but I don't think he would :-).
Actually, I don't care much about those;) The thing is: WebSocket is a
_pragmatic_ effort that takes into account existing Web infrastructure,
JavaScript, and the security issues of running untrusted code in browsers.
If you drop all pragmatism, SCTP (raw ... that is as a new
transport-level protocol besides TCP/UDP directly over IP) or plain TCP
would have cut it right away ...
(I also think SCTP is pretty much doomed unless someone figures out how to run
it on top of UDP or TCP...)
That's already shipping in browsers as of today (Firefox and Chrome) -
WebRTC data channels run over this stack:
+----------+
| SCTP |
+----------+
| DTLS |
+----------+
| ICE/UDP |
+----------+
http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-06
Above is as far as I know the only stack that allows browsers to
communicate peer-to-peer. And it's not only for media, but arbitrary
data. It might get significant .. or not. We'll see;)
/Tobias
-glyph
