Greg, On Tue, May 5, 2009 at 7:33 PM, Greg Wilkins <gregw at webtide.com> wrote: > John Fallows wrote: [snip] >> You seem to have some fairly strong opinions about the direction we >> should be taking here, but as yet I don't have a clear and concise >> understanding of your perspective. Perhaps you could provide a >> concrete proposal for the list to evaluate (in a separate thread) ? > > I definitely have some strong opinions about what problems that > I want solved (eg browser management of connections), but I'm actually > undecided about what is the best technically and practical > solution. Please define the problem you expect "browser management of connections" to solve. For example, what do you anticipate would break without "browser management of connections"? > Thus what I'm asking for in this thread is for people to > discuss the message vs streaming issues, as I see that as > fundamental to all further discussions. > > > For my own part, I can see benefits of both approaches: > > For example, we could advocate a standard HTTP upgrade mechanism > that would require proxies/firewalls to support a class of streaming > protocols (kind of like CONNECT now does for SSL or TLS etc.). > Arbitrary protocols such as Websocket, BEEP, XMPP, etc, etc could all > share that upgrade mechanism and much of our work regarding > tunneling proxies/firewalls would be done. Yes, this is an important idea, especially because it can be achieved by clarifying existing language in the HTTP/1.1 specification only. I'm planning to discuss this in more detail as part of the upcoming "Proxy Traversal Strategy" thread. > However, I think a pure streaming solution would leave many important > issues unresolved (eg security and connection sharing). Even the most advanced messaging protocol with connection sharing still needs to be able to connect before it can share. HTTP Upgrade does a good job of prepending HTTP-based security mechanisms in-band with existing or future TCP-based messaging protocols that are designed to share the connection. > I think that something based around messaging semantics is going to > be much better placed at resolving these issues - even if it does not > open a playing field for arbitrary protocols to compete. > > I also think that a message based solution is much better placed > to build apon the experience of other standards (eg mime encapsulation, > HTTP origin security models, etc). This sounds like you are advocating we design a new general-purpose messaging protocol with wire syntax inspired by HTTP, which implies either HTTP/1.2 or a brand new non-HTTP protocol. In either case, we would still need to define a connection strategy that navigates HTTP proxies, just like we do for the streaming scenario that enables re-use of existing messaging protocols. > Thus my own current preference is a messaging based solution that aspires > to solve more of the problems that I face with my cometd work. What problems do you face with your cometd work today that could not be addressed in a future HTML5 browser by using SharedWorker [1] and HTTP Upgrade with an existing messaging protocol like XMPP, AMQP or STOMP? Kind Regards, John Fallows [1] http://www.w3.org/TR/workers/#sharedworker -- >|< Kaazing Corporation >|< John Fallows | CTO | +1.650.960.8148 888 Villa St, Ste 410 | Mountain View, CA 94041, USA
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.