Re: [hybi] Issue tracker

Jamie Lokier <jamie@shareable.org> Wed, 19 May 2010 02:17 UTC

Return-Path: <jamie@shareable.org>
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 7D84D3A6907 for <hybi@core3.amsl.com>; Tue, 18 May 2010 19:17:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.926
X-Spam-Level:
X-Spam-Status: No, score=-0.926 tagged_above=-999 required=5 tests=[AWL=-0.927, BAYES_50=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 R8sDnmpgMLV8 for <hybi@core3.amsl.com>; Tue, 18 May 2010 19:17:02 -0700 (PDT)
Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 659293A68ED for <hybi@ietf.org>; Tue, 18 May 2010 19:17:02 -0700 (PDT)
Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from <jamie@shareable.org>) id 1OEYq5-0002nc-4N; Wed, 19 May 2010 03:16:53 +0100
Date: Wed, 19 May 2010 03:16:53 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Ian Hickson <ian@hixie.ch>
Message-ID: <20100519021653.GF2318@shareable.org>
References: <4BEA99E9.5050308@ericsson.com> <20100512165946.GC19314@shareable.org> <4BEAF8F6.80709@ericsson.com> <Pine.LNX.4.64.1005130134240.8532@ps20323.dreamhostps.com> <4BEBC177.3030201@ericsson.com> <Pine.LNX.4.64.1005132116210.12269@ps20323.dreamhostps.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.64.1005132116210.12269@ps20323.dreamhostps.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Issue tracker
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: Wed, 19 May 2010 02:17:03 -0000

Ian Hickson wrote:
> > Discussing and building consensus is always a time consuming task, but 
> > it helps a lot in writing a good and robust protocol leveraging on the 
> > help and the experience of a lot of people
> 
> Consensus is not required to write a good and robust protocol leveraging 
> on the help and the experience of a lot of people. Determining consensus 
> also doesn't need to be time-consuming. However, while my preference is 
> for a trivial (and fast!) proven process such as the WHATWG's, as used so 
> far in the development of Web Sockets, I'm willing to use whatever process 
> you come up with, so long as it is clearly defined.

You keep saying WHATWG's process is fast, and presumably you're implying
it manages to leverage the experience of a lot of people.

I'm rather interested.  Can you say a bit about how the WHATWG process
goes about and achieves this, that is different from the process here?

Do you imagine the WHATWG process could achieve the same goals that
appear (to you) to be the aim of the IETF process, but more quickly?

>From my point of view (a distant and oblique observer of parts of
HTML5) the WHATWG process has been good at getting browser vendors to
agree on APIs for fun things that people can hack on top of, instead
of the old days where they hacked on top of browser-specific methods
for many of the same things.  I'm not sure if the WHATWG process has
successfully produced any new or versatile technology that has real
impact on the network, though, and I haven't heard of any way it takes
into account network and server engineering perspectives - which
WebSocket is certainly expected to impact.  If you have shining
examples where it did, that would be interesting.

You may guess that I don't think WHATWG is a good match for the
WebSocket engineering aspects (for the browser API, I'm sure it's
great), which is I guess why the IETF are involved, but I'm more than
curious if there is process you've witnessed/experienced which could
improve the one over here while successfully taking into consideration
network and server engineering perspectives from many experienced people.

Thanks (I mean that),
-- Jamie