On Mon, 29 Jun 2009, Greg Wilkins wrote:
> 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.
>
> 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.
It is a complete compliant implementation of the entire protocol,
including all of the code that would be needed to actually use it. It's
not just the parser, it also does all of the work of listening for new
connections, handling closing connections, etc.
Naturally, this isn't a particular high quality implementation in terms of
handling high load, etc, and I expect that more elaborate implementations
will exist to handle scaling better, etc. However, the 99-line sample is
more than just a demo; it can actually be used to run a real service.
> > 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.
As far as I can tell, it does:
http://damowmow.com/playground/demos/websocket/blank-server.pl
For example, here is a two-player tic-tac-toe server built using the same
code:
http://damowmow.com/playground/demos/websocket/tic-tac-toe.pl
The only part missing in that code is the tic-tac-toe win detection code,
other than that it's a complete server that could run actual two-player
games. It's 148 lines of code (using three built-in Perl libraries
IO::Socket, IO::Select, and Encode, though you could do it using the core
functions directly without much change; I just prefer the OOP-based
interface of the IO libraries).
(I'm not making any claims that the code above is great or scalable or
anything, only that it implements the protocol in a compliant manner and
could be useful in practice for simple situations.)
> 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.
Agreed. The requirement for WebSocket wasn't a specific number of lines of
code; it was just that it should be possible to write the core without
much effort ("a few dozen" lines of code). The idea is just to ensure that
writing a fully-compliant server from scratch is feasible, unlike, say,
with HTTP, where nobody can seriously consider writing a server from
scratch unless they have several weeks or months of time to dedicate to
the task.
I think there are roles to play for both technologies with a tiny server
footprint (like WebSocket) and technologies with serious power and many
features (like HTTP). They are not mutually exclusive.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.