Re: [hybi] Extensibility mechanisms?

Greg Wilkins <gregw@webtide.com> Sat, 17 April 2010 08:50 UTC

Return-Path: <gregw@webtide.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 D16D53A68E9 for <hybi@core3.amsl.com>; Sat, 17 Apr 2010 01:50:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.01
X-Spam-Level:
X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_05=-1.11]
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 LcCyj4XUOBd0 for <hybi@core3.amsl.com>; Sat, 17 Apr 2010 01:50:43 -0700 (PDT)
Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id 533013A6B1E for <hybi@ietf.org>; Sat, 17 Apr 2010 01:50:41 -0700 (PDT)
Received: by bwz25 with SMTP id 25so3880504bwz.28 for <hybi@ietf.org>; Sat, 17 Apr 2010 01:50:30 -0700 (PDT)
Received: by 10.204.10.16 with SMTP id n16mr2381292bkn.173.1271494230199; Sat, 17 Apr 2010 01:50:30 -0700 (PDT)
Received: from [192.168.0.100] (host116-234-static.43-88-b.business.telecomitalia.it [88.43.234.116]) by mx.google.com with ESMTPS id 13sm2240697bwz.15.2010.04.17.01.50.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 17 Apr 2010 01:50:29 -0700 (PDT)
Message-ID: <4BC97653.9000507@webtide.com>
Date: Sat, 17 Apr 2010 10:50:27 +0200
From: Greg Wilkins <gregw@webtide.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Mike Belshe <mike@belshe.com>
References: <h2w5c902b9e1004152345j992b815bz5f8d38f06a19181a@mail.gmail.com> <8B0A9FCBB9832F43971E38010638454F03E3F313E5@SISPE7MB1.commscope.com> <4BC85E60.10501@webtide.com> <4BC88266.7020502@webtide.com> <r2o2a10ed241004160943g87fc24a1zb089a51229a1053a@mail.gmail.com>
In-Reply-To: <r2o2a10ed241004160943g87fc24a1zb089a51229a1053a@mail.gmail.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Extensibility mechanisms?
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: Sat, 17 Apr 2010 08:50:43 -0000

Mike Belshe wrote:
> I have some possibly noobie questions.  I apologize if these have been
> answered before:
> 
> a) In 3.1.2, what is the structure for the length?  I assume its a 4byte
> integer?

Nope - that's the websocket length encoding.  Go figure!

> My biggest complaint:
> The logical unit of operation for a receiver of data over BWTP appears
> to be a "frame batch", not a "frame".  

As I said, it's really just a thought experiment... to see how
websocket might be extended.  I'll ponder your feedback at length
and see if the experiment can be improved.


> One last question, and I hope this won't sound like pride, because it is
> not - I just want to understand. Why not use SPDY for BWTP?  BWTP is
> definitely aimed at the same goals as SPDY, but SPDY is much further
> along.  

I completely agree!   SPDY also has something very vital that BWTP
does not have - interest from a browser vendor!

Perhaps I should switch to thought experiments with SPDY rather
than BWTP - but I wanted to play with the concept of a frame
batch, as I think that is vital to fragmentation of websocket
messages - even though SPDY would not use it.

I think BWTP as a HTTP transport is not very likely.
SPDY over websockets would be a good outcome and we should
strive to make websockets good enough to carry SPDY well.

But perhaps there is some room for a BWTP-like layer between
base websockets and SPDY to provide the fragmentation and
multi-channel stuff as something common to all websocket
users of those facilities.  So maybe I should drop the
HTTP stuff and focus on fragmentation and multiplexing?


> It seems odd to me that first, BWTP defines itself as a "sub-protocol"
> for WebSockets, but then section 3.4 defines how to run WebSockets over
> BWTP :-)  It sounds like indecision.

No - that is running the websocket API over BWTP over websocket
protocol.    Ie aggregating multiple websocket "connections"
over a single real websocket connection, using BWTP.

cheers