W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

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

From: Takeshi Yoshino <tyoshino@google.com>
Date: Sat, 29 Oct 2016 04:05:58 +0900
Message-ID: <CAH9hSJZZCVMpQrpEV_JTceEmf2Y2aC_kJNXJmLW=LPebG+JR7g@mail.gmail.com>
To: Loïc Hoguin <essen@ninenines.eu>
Cc: Costin Manolache <costin@gmail.com>, Wenbo Zhu <wenboz@google.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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.


On Sat, Oct 29, 2016 at 3:12 AM, Takeshi Yoshino <tyoshino@google.com>

> 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
Received on Friday, 28 October 2016 19:06:52 UTC

This archive was generated by hypermail 2.3.1 : Friday, 28 October 2016 19:06:55 UTC