(From #2)
(Bosh)[http://xmpp.org/extensions/xep-0124.html] is an interesting protocol. Like websockets its a bidirection application layer tool, but the implementation is very different. We can test the design of WSGI2 by considering whether BOSH is in-principle able to be carried over it.
One significant and interesting different to Websockets is that the BOSH definition includes the concept of (multiplexing)[http://xmpp.org/extensions/xep-0124.html#multi] - its closer to h2 in that regard. This may help point #10 towards server protocol selection.
It seems to me that we'd want BOSH connection manager requests to be represented as handshakes for new streams, analagous to the websockets discussion. Like in websockets there is a framing layer, and we should expose the (messages)[http://xmpp.org/extensions/xep-0124.html#payloads], not the framing mechanism.
(From #2) (Bosh)[http://xmpp.org/extensions/xep-0124.html] is an interesting protocol. Like websockets its a bidirection application layer tool, but the implementation is very different. We can test the design of WSGI2 by considering whether BOSH is in-principle able to be carried over it.
One significant and interesting different to Websockets is that the BOSH definition includes the concept of (multiplexing)[http://xmpp.org/extensions/xep-0124.html#multi] - its closer to h2 in that regard. This may help point #10 towards server protocol selection.
It seems to me that we'd want BOSH connection manager requests to be represented as handshakes for new streams, analagous to the websockets discussion. Like in websockets there is a framing layer, and we should expose the (messages)[http://xmpp.org/extensions/xep-0124.html#payloads], not the framing mechanism.