Re: WiSH: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols (HTTP)

About changing the framing and other things, I think this is wrong. The way
WiSH currently is presented is perfect for quick adaptation.  Any changes
to framing or how it works will greatly delay browsers adding it as they
will have to change client code related to websockets.  Removing the mask
for example is fine, the browser will just always set the MASK bit to 0.
No need to change any client code.

On Fri, Oct 28, 2016 at 3:05 PM, Takeshi Yoshino <tyoshino@google.com>
wrote:

> Sorry for being ambivalent.
>
> We can of course revisit each design decision we made for RFC 6455 framing
> and search for the optimal again. But as:
> - one of the main philosophies behind WiSH is compatibility with WebSocket
> in terms of both spec and implementation
> - the WebSocket is widely deployed and therefore we have a lot of
> implementations in various languages/platform
> - most browsers already have logic for the framing
> - the framing is not considered to be so big pain
> inheriting the WebSocket framing almost as-is is just good enough.
> Basically, I'm leaning toward this plan.
>
> Takeshi
>
> On Sat, Oct 29, 2016 at 3:12 AM, Takeshi Yoshino <tyoshino@google.com>
> wrote:
>
>> On Sat, Oct 29, 2016 at 2:55 AM, Loïc Hoguin <essen@ninenines.eu> wrote:
>>
>>> On 10/28/2016 08:41 PM, Costin Manolache wrote:
>>>
>>>> Current overhead is 2 bytes if frame is up to 125 bytes long - which I
>>>> think it's not very common,
>>>> 4 bytes for up to 64k, and 10 bytes for anything larger.
>>>> IMHO adding one byte - i.e. making it fixed 5-byte, with first as is,
>>>> and next 4 fixed length would
>>>> be easiest to parse.
>>>>
>>>
>>> Is making it easy (or easier) to parse even a concern anymore?
>>>
>>> Considering the number of agents and servers already supporting
>>> Websocket, the numerous libraries for nearly all languages and the great
>>> autobahntestsuite project validating it all, reusing the existing code is a
>>> very sensible solution.
>>>
>>>
>> Yeah, I've been having similar feeling regarding cost for parser/encoder
>> implementation though I might be biased.
>>
>>
>>> There are obviously too many options to encode and each has benefits -
>>>> my only concern was
>>>> that the choice of 1, 2, 8 bytes for length may not match common sizes.
>>>>
>>>> ( in webpush frames will be <4k ).
>>>>
>>>
>>> --
>>> Loïc Hoguin
>>> https://ninenines.eu
>>>
>>
>>
>