Re: [hybi] WebSocket and metadata (Was: BWTP Proposal - Bidirection Web Transfer Protocol)

[Greg Wilkins <gregw at webtide.com>]

Jamie Lokier wrote:
> Greg Wilkins wrote:
>> The additional code needed
>> to modify an existing HTTP parser to BWTP should be no more than a
>> few lines of code.
> 
> I think it's disingenuous to portray BWTP as a few lines of code,
> because nobody worries about a "HTTP parser", and nobody uses a "HTTP
> parser library" which would be changed for BWTP.

Jamie,

that is true - but I was trying to compare apples with apples, as
I think a perl program that runs the websocket protocol is little
more than a parser.


> Most servers only parse requests and emit responses, and dispatch those
> requests and responses in a particular way, often with multiple
> processes or threads, or sometimes in sequence.
> 
> BWTP changes that pattern quite significantly, and that's where the
> interesting part goes.

Indeed.   That part falls into providing an application framework
and I think is vital work to abstract an application developer
away from the nuts-and-bolts of a protocol.



> Of course any bi-directional protocol we're discussion does the same.

Agreed.  But this work is also not included in the "few lines" estimate
for the websocket implementation.


> The point is that with the effort to build something which handles
> bi-directional messaging, the actual *parser* is not likely to be
> something to worry about.  Really, the tricky stuff is in keeping
> sockets alive, timeouts, flow control, orderly shutdowns, retries,
> handling protocol errors.

Here I think BWTP will be able to expand on existing HTTP connection
handling.  However it remains to be seen how much will need to be
changed - and I expect it will be more than initially expected.


> That stuff applies with any of the bi-directional protocols, even the
> ones which haven't said anything about it because they haven't been
> implemented and tested yet.  Some of them expect Javascript
> applications to deal with it (which imho is a nice way to ensure low
> quality implementations.)

I generally agree with the sentiment of your post, because I think that
the lines-of-code measure is a poor metric on which to evaluate proposed
protocols.

Having said that, the complexity of implementation is indeed a good
gross measure that should be considered.   For example, my earlier
advocacy for considering BEEP has been dulled because people pointed
out some of the non-trivial complexities that would need to be implemented.

cheers