Re: [hybi] Is there a traffic jam?

[Greg Wilkins <[e-mail]>]

Ian Hickson wrote:
> On Mon, 13 Apr 2009, Thomson, Martin wrote:
>> Some do the right thing.  Others do what you might fear.
> 
> This is roughly why I believe one of our requirements should be that 
> implementations should be possible in few lines of code without the use of 
> any libraries. Sure, HTTP libraries are a dime a dozen, and we can rely on 
> XML parsers and so on, but in practice, some will do the right thing, and 
> others won't.
> 
> I'd rather have a protocol that's so simple that nobody will feel the need 
> to write their own HTTP parser, say.

Ian,

the problem with a really simple protocol is that encourages wheels to
be reinvented further up the stack.

Not supporting features in the base protocol does not
make these things not a problem - it just makes them somebody
else's problem.

eg just because the base transport does not support multi-channel
interleaved messages with flow control, does not mean that
such requirements are not needed.

If for example we picked Websocket as *THE* protocol and
all the firewalls and gateways were changed to support upgrade
to websocket - then I would still expect to see many different
protocols being tunnelled over websocket datagrams.

These may be application specific protocols based on UTF-8
datagrams or they may even be existing protocols such as BEEP
tunnelled over websocket binary datagrams.

There would still need to be conventions or standards so
that we could work out that the websocket datagram really
does contain the protocol we are expecting, and then that
protocol will need to be implemented with all it's parsers
and libraries.


The question is - is there a reasonable subset of features
that could be supported at the base protocol level that
would reduce the number of reinvented wheels.

I really liked Jamie Lokiers suggestion of a set of optional
extension to HTTP, so that minimal implementations need only
implement the features that they need.   Thus support of
multiplexed interleaved messages with flow control would
not be manditory, but also would not have to be reimplemented
by every stack that needed it.


cheers