Re: [hybi] Technical feedback. was: Process!

Maciej Stachowiak <mjs@apple.com> Sat, 30 January 2010 06:49 UTC

Return-Path: <mjs@apple.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 E49393A6805 for <hybi@core3.amsl.com>; Fri, 29 Jan 2010 22:49:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.171
X-Spam-Level:
X-Spam-Status: No, score=-106.171 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 4xGgfD3JI+Rd for <hybi@core3.amsl.com>; Fri, 29 Jan 2010 22:49:10 -0800 (PST)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 10A203A6405 for <hybi@ietf.org>; Fri, 29 Jan 2010 22:49:10 -0800 (PST)
Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id 6848E89451EA for <hybi@ietf.org>; Fri, 29 Jan 2010 22:49:35 -0800 (PST)
X-AuditID: 11807136-b7bafae000000e8d-5a-4b63d67fa5cd
Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay15.apple.com (Apple SCV relay) with SMTP id 36.D2.03725.F76D36B4; Fri, 29 Jan 2010 22:49:35 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from [17.151.93.115] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KX1005FCSAM3R90@et.apple.com> for hybi@ietf.org; Fri, 29 Jan 2010 22:49:35 -0800 (PST)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <4B636757.3040307@webtide.com>
Date: Fri, 29 Jan 2010 22:49:34 -0800
Message-id: <BBF3CE06-3276-4A7C-8961-7B3DDEE406D0@apple.com>
References: <de17d48e1001280012i2657b587i83cda30f50013e6b@mail.gmail.com> <4B620B8F.6030706@gmx.de> <Pine.LNX.4.64.1001282217320.22053@ps20323.dreamhostps.com> <bbeaa26f1001281449q1a6e1813q3f537fe15a5a9d60@mail.gmail.com> <4B625733.2020907@webtide.com> <6.2.5.6.2.20100128225542.06fa8d68@resistor.net> <Pine.LNX.4.64.1001290817520.22020@ps20323.dreamhostps.com> <4B62C5FE.8090904@it.aoyama.ac.jp> <Pine.LNX.4.64.1001291134350.22020@ps20323.dreamhostps.com> <4B62E516.2010003@webtide.com> <5c902b9e1001290756r3f585204h32cacd6e64fbebaa@mail.gmail.com> <4B636757.3040307@webtide.com>
To: Greg Wilkins <gregw@webtide.com>
X-Mailer: Apple Mail (2.1077)
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Technical feedback. was: Process!
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, 30 Jan 2010 06:49:11 -0000

Here's comments on some of the issues that did not seem to me to merit their own thread.

On Jan 29, 2010, at 2:55 PM, Greg Wilkins wrote:

> 
> It was a little silly having to implement two framing mechanisms
> when only one of them has an API to enable it's usage.

This is a little lame, but it will ultimately be fixed at the API level once we have a good way to represent binary data on the client side.

> 
> So if you look on the wire of cometd running over websocket,
> it just looks like long polling.  We use the same /meta/connect
> long poll message as a keep alive and as our ack carrier.
> 
> We've saved 1 connection, which is great.   But I fear that
> saving will be eaten up by the ability of application developers
> to open any number of websockets.

Doesn't it also save you the need to potentially close and reopen the connection that would have been used for messages from the client to the server? It seems like proper full duplex is a significant win, especially over SSL where connection setup is very expensive.

> 
> If we are not running in reliable message mode, then we don't
> need to wait for a /meta/connect before sending a message
> to the client, so we get a small improvement in maximal
> message latency for current usage and a good improvement
> for streaming usage.

Wouldn't you also get an improvement in throughput, and not just latency, for streaming since you no longer need to repeatedly send full HTTP headers?

> But as I've frequently said, it works ok, but it solves
> few of my real pain points as comet vendor and it's
> caused me more code/complexity not less.

I'm curious to hear about some of the pain points that you think are not addressed. You mentioned two (reliable message delivery and maintaining idle connections) and I think you're right that those should be addressed. Any others?

> It's not provided any semantics that would allow
> any cometd users to consider going directly to websockets
> instead of using a comet framework.   Sure it makes sending
> messages easy, but that is always easy. It does not help
> for when you can't send messages or when connections drop
> or servers change etc.   These are all the realworld things
> that must be dealt with and ws makes this harder not easier.

What kind of changes do you think would make it more practical to use WebSocket directly rather than go through a framework?

Regards,
Maciej