Re: Providing two-way communication back to a server from a Web page

Robert Brewer wrote:
> Second, Python web frameworks at least have pretty much standardized now
> on the Web Server Gateway Interface [1], which is strictly
> request/response. Rewriting WSGI, and/or extending the servers, to use
> WebSockets would be nontrivial. I imagine most other existing web
> frameworks in other languages are similarly bound to that model.

Can you overlay something like Bayeux
(http://svn.cometd.com/trunk/bayeux/bayeux.html) over WSGI?

Ugly, but as a transition mechanism may be usable.

> Third, I've seen too many custom TCP protocols in my day, and am quite
> concerned this would be a step backwards into some pretty ugly RPC. Not
> just hard to read, but lacking any visibility or most of the other
> network-architectural benefits we've come to rely on in HTTP.
> 
> Synthesizing those, I'd feel better about WebSockets if the messages
> passed in both directions were HTTP, not opaque binary formats.

People don't have to opaque, binary RPC over it.  If they want, they
can send HTTP style messages over it.  The question is, do you want to
suggest a common way to do that, or attempt to force it?

> I also wonder if this couldn't be better achieved by creating a spec
> (HTTP 2?)  that allowed pipelined HTTP request and response messages
> in both directions arbitrarily.

If you do that, you probably need an ability to send out-of-order
responses tagged by their corresponding request, possibly multiplex
responses, and if multiplexing also you'll need per-response flow
control to avoid starvation/unbounded-buffer problems.

Personally I think it's a good idea :-)  But that's because I have an
application which roughly does that, inspired by HTTP and those sort
of extensions, and it works (but drifted from HTTP a bit in the process).

One of the downsides of your suggestion is you don't always want a
response to every message.  That can be wasteful.  So you also want
responsless messages.  Publish-subscribe methods which don't require a
HTTP round-trip just to setup and teardown have uses too.  In complex
mobile applications, you want to keep down the round trip latency
cascade.

With a compatibility mechanism, two-way messaging extensions can be
overlaid on top of HTTP/1.1 if you're feeling brave, using any of the
existing two-way communication hacks.  Stretch and hand-waving, I can
just about imagine a HTTP/2 doing it neatly, with implementations able
to fall back to a HTTP/1.1 overlay hack when a HTTP/2 path to the
server isn't available.

-- Jamie

Received on Saturday, 10 January 2009 01:23:59 UTC