Re: [hybi] Framing take IV

[Jamie Lokier <[e-mail]>]

Ian Fette (イアンフェッティ) wrote:
> 
>    On Tue, Aug 3, 2010 at 9:13 PM, Ian Hickson <[1][e-mail]> wrote:
> 
>    On Tue, 3 Aug 2010, Scott Ferguson wrote:
>    > Ian Hickson wrote:
>    > > On Tue, 3 Aug 2010, Scott Ferguson wrote:
>    > > > > Â  I agree. I can't see any benefit to fragmentation over a
>    > > > > variable-size length field for an initial version without
>    > > > > multiplexing. If the variable-size length field is
>    well-designed,
>    > > > > then in the common case where the message size is small it
>    will
>    > > > > only cost one extra branch to read the length. In the rare
>    case
>    > > > > where the message size is large, a variable-size length is
>    easier
>    > > > > to deal with than reassembling fragments, and easier on the
>    > > > > sending side too.
>    > > >
>    > > > Some of us don't have infinite memory when sending messages.
>    > >
>    > > Why do you need infinite memory?
>    >
>    > Because we don't know the length of dynamically produced content
>    until
>    > the dynamic process is complete. That's why HTTP added chunking.
> 
>      Is this a common case we should expect? What are the use cases for
>      this?
>      If this is a rare occurence, then it's probably simplest to support
>      this
>      at the application layer - nothing stops anyone from having a
>      subprotocol
>      that defines the first byte/character of each message as being a
>      "has continuation" byte.
>      If this is a common occurance, then we'll be able to tell when
>      people find
>      themselves often implementing this at the application layer, and
>      then we
>      can easily add it at the WebSocket layer at that time (in a few
>      months).
>      We don't need to reserve bits specifically for it today.
> 
>    We're adding a voice input capability, and we want to start sending
>    the user's voice up as soon as they start speaking, without waiting
>    for the recording to be finished so that we can start backend
>    processing. Yes, we could probably break it into multiple messages,
>    but given that semantically it's a single message, this is a case
>    where we would want to start sending data before knowing its length.
>    Ditto for hooking up a video camera and sending that data to some sort
>    of web service.

Ah, not really.

That one is better following Ian Hixie's method of application-visible
concatenation.  The JS API is defined to not deliver a message until
the whole message is received (even if we specify split-message chunks
in the protocol), so a JS application would not see the voice data
until a message boundary.

While other clients can use different APIs, we should try to match the
behavioural characteristics of the JS API as closely as possible for
the sake of interoperability.

There is another important reason: Intermediary behaviour isn't well
defined yet, but it would not be unreasonable for an active
intermediary to arbitrarily delay parts of a partially received
message, for example to compress the whole message (or large parts),
or forward more efficiently.

Basically, message boundaries are the only guaranteed delivery points,
and as the voice/camera application needs to guarantee regular
deliveries, it should mark those delivery points explicitly by making
them message boundaries, not chunk boundaries.

-- Jamie