Re: [hybi] Framing take IV [why fragment]

Scott Ferguson <ferg@caucho.com> Thu, 05 August 2010 13:38 UTC

Return-Path: <ferg@caucho.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 ED80B3A6B1B for <hybi@core3.amsl.com>; Thu, 5 Aug 2010 06:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
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 U4PTCffqdLmn for <hybi@core3.amsl.com>; Thu, 5 Aug 2010 06:38:33 -0700 (PDT)
Received: from smtp115.biz.mail.re2.yahoo.com (smtp115.biz.mail.re2.yahoo.com [66.196.116.35]) by core3.amsl.com (Postfix) with SMTP id 19B3A3A69E0 for <hybi@ietf.org>; Thu, 5 Aug 2010 06:38:32 -0700 (PDT)
Received: (qmail 77830 invoked from network); 5 Aug 2010 13:38:59 -0000
Received: from scott-fergusons-macbook-pro-3.local (ferg@71.141.247.84 with plain) by smtp115.biz.mail.re2.yahoo.com with SMTP; 05 Aug 2010 06:38:59 -0700 PDT
X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C
X-YMail-OSG: NLj13zwVM1ncK83fLHj8sHZ5nJbr7mG5wnQNkNe5CCX8wV1 AyKnHjwcKNEdNhWfoMKQaspmHMQSirQHiZRaMhBniYCZh46MI4oRUhWUco9o BdLMK8SNyaV56Ue0yocZ7hsgx9lhlQKU0xjxZbMSaU1S_97H1HzDL_VK4V39 IvJMh11E.4KYFUDUiYvx_jB4YoqZp2blK0PsDemy4Po.naKfaH5.KeFW8MVK aYFYrvgI57VrEDtDQXPsNBTjV9gaiXvCyGesk9rEWUVnT1yVDbTdp_kLW7Ll SB4KEHNrNy6RjQaNzNmU.QowZup_gnDXNpiEPk8n28GhlowkBiq75g4TPYFy RTnShRPjAL3cgpNYtg_cS2.lXzTG6_a1GaqIr70FV.y8GiETCjRcj2Sj0WdI a6_xAbtC4T9OngrW8BAIKxWo-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4C5ABEF2.6010505@caucho.com>
Date: Thu, 05 Aug 2010 06:38:58 -0700
From: Scott Ferguson <ferg@caucho.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Ian Hickson <ian@hixie.ch>
References: <AANLkTinyrDoG5d_Ur6HVRy=SgMPjLzJtpJ++Ye=1DQdj@mail.gmail.com> <Pine.LNX.4.64.1008040050040.5947@ps20323.dreamhostps.com> <AANLkTi=3CJDKu37LV+6CG=d7VP5fOe-JNV9Cd=99BjjA@mail.gmail.com> <2AD09E86-CFFE-4378-A437-7EAE2E3026FD@apple.com> <1280937841.7561.292.camel@tng> <Pine.LNX.4.64.1008041754000.5947@ps20323.dreamhostps.com>
In-Reply-To: <Pine.LNX.4.64.1008041754000.5947@ps20323.dreamhostps.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org
Subject: Re: [hybi] Framing take IV [why fragment]
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Thu, 05 Aug 2010 13:38:39 -0000

Ian Hickson wrote:
> On Wed, 4 Aug 2010, Patrick McManus wrote:
>   
>> But I also believe fragments with fixed lengths are simpler than a BER 
>> because properly aligned lengths are always correct data - there are no 
>> error cases as all the bits are defined to be some quantity regardless 
>> of their arrangement. BER has error cases and determining the expressed 
>> quantity requires multiple indirections and a significant algorithm to 
>> use it.
>>     
>
> As far as I can tell there are no error cases as defined in WebSockets.
>
> Variable-width lengths also doesn't preclude chunking at a future point 
> should it prove to be needed (which we would be able to tell because we 
> would see authors making their application-layer protocols implement 
> chunking on top of WebSockets).
>   

No.

Chunking is a direct consequence of using a buffered stream, like fwrite 
and fread. It is not an application-level concept at all. If you do not 
add chunking, an implementation cannot implement an efficient basic 
stream for it.

If you do not understand why server-side HTTP use streams as the basic 
interface: CGI, PHP, Java, etc, you don't understand HTTP.  If you do 
not understand how streams work or understand why servers would choose 
that API, then you don't understand the basic concepts of chunking.

If you do not understand how fwrite works, or think fwrite or PHP's echo 
or CGI or Java's OutputStream are enormously-complicated concepts (or 
even new technology), then you might consider refraining on commenting 
on the usefulness of chunking until you learn these basic concepts.

-- Scott