[whatwg] BWTP for WebSocket transfer protocol

[Jonas Sicking]

On Fri, Aug 7, 2009 at 10:07 PM, Greg Wilkins<gregw at mortbay.com> wrote:
>
> 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 think that might be the case. At least for general-purpose metadata.
The only thing that I can think of that might be useful to support
per-frame is content-encoding/transfer-encoding, but I could probably
be talked out of that too.

>> 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 :).

Good to hear.

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

Out of curiosity, what advantages do you see with having a declared
content-type? I can think of a few, but wanted to know which ones you
had in mind.

Also, what do you mean by "orderly close"?

As far as specification style (BNF or not), I personally don't really
care there, as long as it's well defined how to handle all possible
inputs, valid or invalid.

I'm also unconvinced that per message meta data is needed.

Other than that I largely agree.

/ Jonas