Re: [hybi] Extensibility mechanisms?

Greg Wilkins <> Sat, 17 April 2010 08:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D16D53A68E9 for <>; Sat, 17 Apr 2010 01:50:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.01
X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_05=-1.11]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LcCyj4XUOBd0 for <>; Sat, 17 Apr 2010 01:50:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 533013A6B1E for <>; Sat, 17 Apr 2010 01:50:41 -0700 (PDT)
Received: by bwz25 with SMTP id 25so3880504bwz.28 for <>; Sat, 17 Apr 2010 01:50:30 -0700 (PDT)
Received: by with SMTP id n16mr2381292bkn.173.1271494230199; Sat, 17 Apr 2010 01:50:30 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id 13sm2240697bwz.15.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 17 Apr 2010 01:50:29 -0700 (PDT)
Message-ID: <>
Date: Sat, 17 Apr 2010 10:50:27 +0200
From: Greg Wilkins <>
User-Agent: Thunderbird (X11/20100411)
MIME-Version: 1.0
To: Mike Belshe <>
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Cc: Hybi <>
Subject: Re: [hybi] Extensibility mechanisms?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.