[whatwg] BWTP for WebSocket transfer protocol
gregw at mortbay.com
Fri Aug 7 22:07:52 PDT 2009
taking some of your comments out of order....
> My gut feeling on BWTP vs. websocket is that BWTP carries some
> unneccesary complexity/overhead by allowing arbitrary headers in each
> frame, whereas websocket is unnecessarily low level.
I added the headers to BWTP (headers), because I didn't like the
total lack of meta data in websocket. I then added virtual
But now you mention it, arbitrary headers in each frame is probably
excessive since it could be argued that all the messages to/from a
given URI are likely to have mostly same metadata so perhaps a protocol
that supports virtual connections does not need per message
meta data. So maybe metadata per virtual connection meta-data is
> I don't think BWTP gains a lot by using HTTP-like syntax, as I don't
> think that in reality a lot of existing HTTP code can be reused.
I don't think HTTP-like syntax is essential. I was just using
it to start from a familiar place. It is the features that
BWTP has that Websocket lacks that I think are important
(plus I admit a total dislike of 0 delimited framing :).
> I agree that these are very interesting features. Especially
> connection multiplexing is something that I think is a good idea, for
> the reasons you've mentioned elsewhere in this thread (multiple
> widgets on the same page). But even compression is nice if it was
Indeed it is the features that are more important ideas in BWTP
rather than the syntax of the protocol.
The features that I feel are important to have in the protocol
+ mime encapsulated content types (not just utf-8 and binary).
+ extensible content-encoding and/or transfer encoding
+ orderly close
Nice to have features include:
+ message segmentation (good for flow when multiplexing).
+ intermediary participation
+ strict in what you generate, forgiving in what you parse
+ BNF style specification rather than algorithmic specification.
+ per message meta data
> My impression is like Maciejs, that we wouldn't be able to reuse much
> of our current HTTP infrastructure in order to implement BWTP. At
> first glance only the header-parsing code would carry over directly,
> but that's not many lines of code and so doesn't seem like a big win.
Again this is valuable feedback.
That's three -0' or -1's on the look-a-like-HTTP approach.
I'll ponder what sort of simplifications could be made
if the HTTP style is dropped.
More information about the whatwg