Re: [hybi] Framing take IV

Ian Fette (イアンフェッティ) <ifette@google.com> Wed, 04 August 2010 04:16 UTC

Return-Path: <ifette@google.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAB9B3A6B9E for <hybi@core3.amsl.com>; Tue, 3 Aug 2010 21:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.457
X-Spam-Level:
X-Spam-Status: No, score=-101.457 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ktzb5Ya4Msgz for <hybi@core3.amsl.com>; Tue, 3 Aug 2010 21:16:25 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 235F23A69CB for <hybi@ietf.org>; Tue, 3 Aug 2010 21:16:24 -0700 (PDT)
Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id o744Grb0024798 for <hybi@ietf.org>; Tue, 3 Aug 2010 21:16:53 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280895413; bh=RPGlZBl7WWuKhTKOxc80jtqwqFQ=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=uHXD9n0xfMGsz5kvQvhAFOvtLSEg1R+vALqmkBYn+/jMHJsg4oshgT9B16lCU7W82 kxm15SDEZdzMbb8JY2Oyw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:reply-to:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=sI9zlas3weuP6q0U8k6xk+oDepF0L4bknY20snTaBUmlrHU6SaPBNzQFPrGBxr1TL zPZ7lR0S7rqx/qc93GXUA==
Received: from ywa6 (ywa6.prod.google.com [10.192.1.6]) by wpaz9.hot.corp.google.com with ESMTP id o744GqQJ029679 for <hybi@ietf.org>; Tue, 3 Aug 2010 21:16:52 -0700
Received: by ywa6 with SMTP id 6so2211799ywa.23 for <hybi@ietf.org>; Tue, 03 Aug 2010 21:16:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.63.26 with SMTP id q26mr9834170ybk.193.1280895408864; Tue, 03 Aug 2010 21:16:48 -0700 (PDT)
Received: by 10.150.67.19 with HTTP; Tue, 3 Aug 2010 21:16:48 -0700 (PDT)
In-Reply-To: <Pine.LNX.4.64.1008040139520.5947@ps20323.dreamhostps.com>
References: <AANLkTinyrDoG5d_Ur6HVRy=SgMPjLzJtpJ++Ye=1DQdj@mail.gmail.com> <Pine.LNX.4.64.1008040050040.5947@ps20323.dreamhostps.com> <28A6543A-5CA6-42B7-8D2E-F5511EE20008@apple.com> <4C58C2F6.8050608@caucho.com> <Pine.LNX.4.64.1008040132190.5947@ps20323.dreamhostps.com> <4C58C4C8.5020900@caucho.com> <Pine.LNX.4.64.1008040139520.5947@ps20323.dreamhostps.com>
Date: Tue, 03 Aug 2010 21:16:48 -0700
Message-ID: <AANLkTinp7UmROSCRSvuj_AKcMT4OnhWebPCD-z_60LZZ@mail.gmail.com>
From: "Ian Fette (イアンフェッティ)" <ifette@google.com>
To: Ian Hickson <ian@hixie.ch>
Content-Type: multipart/alternative; boundary="000e0cd5958ed6fea7048cf7b373"
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] Framing take IV
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Aug 2010 04:16:26 -0000

On Tue, Aug 3, 2010 at 9:13 PM, Ian Hickson <ian@hixie.ch> 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.



> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>