We already support websockets as transport in the server, see #1136 / #1134, so we could support websockets in the python client as well. (we already have ssh, ssl, tcp and unix / named-pipes!)
I don't see the point of adding this one: we try hard to avoid copying data in the network layer and using websockets will cause more of it, using more CPU.
Found: https://github.com/liris/websocket-client which supports python 2. This may help with things like #1298.
Implemented basic support in r13558, hoping this will help debug #1298. You can now connect using a websocket transport:
xpra attach ws/127.0.0.1:10000/
Looking at the traffic, it's not pretty: redundant size headers, etc... #1134 may help a bit here, but ultimately this transport is very unlikely to ever perform as well as the plain xpra protocol it wraps.
Still TODO:
Minor updates:
ws[s]/username:password@host:port/path?arg=val&etc
xpra attach wss:127.0.0.1:10000 --ssl-ca-cert=./ca.crt
(successfully establishes the SSL connection to the server but then fails because of the issue in ticket:1213#comment:3)
Excluding the wss issue above, this is ready for testing. See also #1213 @afarr: you should be able to use ws URL connection strings with the latest clients. This is useful for testing the same transport layer used by the html5 client.
Interesting. Tested the permutations with 1.0.6 r15627 osx client (10.12) against a 1.0.7 r16032 fedora 25 server.
Each permutation worked without so much as a wrinkle. Good to know the clients will work over the same transport layer.
Closing.
See also #2121
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1271