> > I am working on Twisted Endpoint support in Autobahn > https://github.com/tavendo/AutobahnPython. > > Yay!
Endpoints are cool. FWIW, here is a working example of WebSocket I tested over both Unix domain sockets and the usual TCP/TLS endpoints: https://github.com/tavendo/AutobahnPython/tree/master/examples/websocket/echo_endpoints This works with all features Autobahn provides like support for different WebSocket versions (Hixie-76, RFC6455) and WebSocket extensions (like permessage-compression with deflate, snappy, bzip2). [snip: talk on Endpoints for Serial and Process] > I hope you'll poke those tickets along through the process. Thanks for directions! I will have a look into those. > There's totally a plugin architecture for this, and I'm excited for you to > use it :- > ). > > One quick comment though: would you be OK with using 'autobahn' as your > identifier rather than 'websocket'? There are still plans to include basic > websocket support within Twisted itself and it would be a shame to start > conflicting on that identifier. Sure. Can I use: "autobahn.websocket" ? Since Autobahn also provides other protocols (WAMP), and .. == Thanks for your pointers on the Endpoint plugin architecture. I guess thats enough to get me started - modulo below .. if you could give me 1 more reply with feedback, that would be awesome! In the meantime I did a little more thinking about WebSocket and endpoints. I can see two approaches - which one is the way forward? Variant 1) endpoint = serverFromString(reactor,"autobahn.websocket: tcp:80:url=ws://myhostname.com/somepath") Here, a single endpoint descriptor is specifying parameters for both WebSocket, and the underlying transport. Underlying transport: tcp:80 WebSocket overlay: autobahn.websocket:url=ws://myhostname.com/somepath:extensions:permessage-deflate;permessage-snappy So the plugin needs to parse not only the "overlay transport" spec, but also the underlying spec ("tcp:80") and all variants thereof? Or can I let the existing Twisted machinery do the parsing of the underlying, and only parse off the remaining stuff ("url=ws://myhostname.com/somepath:extensions:permessage-deflate;permessage-snappy" in this case) And if not, does that mean not only the endpoint main identifier ("tcp" vs "unix" vs "autobahn.websocket") must be non-overlapping, but also all the individual parameters? Like in the case for WebSocket, there is a need for a "url" parameter. These Qs have brought me to .. Variant 2) endpoint = serverFromString(reactor, "tcp:80") wrappedEndpoint = serverFromString(reactor, endpoint, "autobahn.websocket:url=ws://myhost.com/mypath") where I would start a program like python myprog.py --transport "tcp:80" --wrappingTransport "autobahn.websocket:url=ws://myhost.com/mypath" Is there such thing as a WrappingEndpoint? == This is yet another topic/question, but it fits here. Twisted has defined interfaces for both stream (and datagram transports). WebSocket is essentially a bidirectional, reliable, ordered datagram transport (with 2 payload types: binary and utf8). Is there a Twisted Interface for such transports? I am asking, since I am right now also refactoring the code within Autobahn that lays above raw WebSocket .. a PubSub+RPC protocol, that essentially only assumes a transport like above. I want to make it independent of WebSocket and only assume a bidirectional, reliable, ordered, datagram transport. Thanks a bunch for your thoughts and help! /Tobias _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
