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

[Costin Manolache <[e-mail]>]

Good point - websocket is widely deployed, including IoT - and the header
is pretty easy to handle anyways.
+1.

One question: is this intended to be handled by browsers, and exposed using
the W3C websocket API ?
Will a regular app be able to make WiSH requests and parse the stream by
itself, without browser
interference ? And if yes, any advice on how it interact with CORS ?

Costin

On Fri, Oct 28, 2016 at 12:06 PM Takeshi Yoshino <[e-mail]>
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 <[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
>
>
>
>