Re: [hybi] WebSockets feedback (Was: Bayeux / Jetty perspective.)

[Paul Prescod <[e-mail]>]

In general, the benefit of using an existing protocol is that you take
advantage of a lot of infrastructure and in particular of protocols built ON
TOP of that protocol. Maybe that doesn't matter for train control, but it
matters a lot for webchat, which as far as I'm concerned is the single
biggest application of a "server->client" protocol. To me, this strongly
suggests Jabber, but I'll make the case for HTTP because I'm more familiar
with it:

 * new specification is very short and simple (e.g., not much more than [1])

 * client-libraries and intermediaries are more easily adapted (e.g. Curl,
httplib, ...)

 * domain knowledge is easily applied ("it's just like writing a PHP script
except you use Javascript and listen to Firefox rather than Apache")

 * standards built on HTTP will work more easily (cookies, AtomPub, WebDAV,
Subversion, etc.)

 * in general, the information system called "the Web" will have fewer
protocols and will be simpler, which will help it evolve and survive in the
long run. For example, if we add message signing to HTTP then we get it "for
free" in both directions. If we add a reliability protocol to HTTP then we
get it "for free" in both directions. ("for free" from a specification point
of view...from an implementation point of view it is "for cheap" because you
can reuse C code between Firefox and Apache if you like, or IIS and IE,
etc.)

That all said, my current feeling is still that Jabber is the best choice
because it is already the dominant protocol for the asynchronous
bi-directional use cases we're talking about. But I really cannot see the
advantage in inventing a new protocol from scratch. The Web and Internet are
complicated enough as they are without a proliferation of framing protocols.

 Paul Prescod

[1] http://www.ietf.org/internet-drafts/draft-lentczner-rhttp-00.txt