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

[Takeshi Yoshino <[e-mail]>]

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 <[e-mail]>
wrote:

> On Sat, Oct 29, 2016 at 2:55 AM, Loïc Hoguin <[e-mail]> 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
>>
>
>