Re: [hybi] ws and bwtp thoughts

[Greg Wilkins <[e-mail]>]

Thomson, Martin wrote:
> You make some good points there, but then use that as a 
> vehicle for expressing your opinion.

can't help myself :)


>> If you are concerned about reducing data usage,
> 
> That's another variable in the mix.  I personally tend to 
> value aspects like maintainability more highly.
> 
> Sure, metadata overheads are high, relative to our 
> expected payload, but given the nature of the
> problem space, I believe that there are better ways to
> spend our specification/implementation complexity budget
> than on such optimizations.

I can see both sides of this.

Needless to say that even with per message meta-data, I think we
can do a lot better than HTTP which has a lot of request/response
baggage in the accept-xyz headers.

So I don't think that we should immediately conclude that if
per message meta-data is supported, then we are going to see
hundreds of extra bytes per message.

One suggestion I have made previously is to simply define
another type byte for websocket that would mean the content
is mime encoded content with standard headers terminated by
CRLFCRLF.     To put that into my simplified websocket BNF
without channels is:

    ws1-frame           = frame-length
                          frame-type
                          octet-data

    frame-type          = 0x00    ; utf8 frame
                        / 0x01    ; mime encoded frame
                        / 0x02-FF ; undefined binary frame

    frame-length        = unlimited-integer

    unlimited-integer   = *( %x80-FF ) %x00-7F
                        ; concatenate 7 low order bits from each octet
                        ; to form a binary integer

    octet-data          = *( %x00-FF )
                        ; the number of octets is exactly the length determined
                        ; by the frame-length

But this would probably need either some websocket API changes
or some serious extra header conventions to allow transparent
sharing  of TCP/IP connections between websocket "connections",
but it at least opens the possibility.

In fact, header conventions could also be used to
implement channels and other protocol extensions without
needing to put them into the framing.

I think the cat is feeling very nervous about all
the different types of knives that can be used !

However, transporting mime encoded content is such an
obvious thing to do, that the strenuous rejection of
defining a type value for it made me even more concerned
about the non extensible nature of a fixed type byte
mapping.


cheers