[whatwg] BWTP for WebSocket transfer protocol

[Greg Wilkins]

Jonas,

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
connections afterwards.

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
sufficient?


> 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
> possible.

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
are:

  + mime encapsulated content types (not just utf-8 and binary).
  + extensible content-encoding and/or transfer encoding
  + multiplexing
  + 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.


cheers