Re: [hybi] Apples and Orangutans

Jonas Sicking <jonas@sicking.cc> Tue, 14 April 2009 01:28 UTC

Return-Path: <jonas@sicking.cc>
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 600A63A68AA for <hybi@core3.amsl.com>; Mon, 13 Apr 2009 18:28:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 Fif+-0uGtb7n for <hybi@core3.amsl.com>; Mon, 13 Apr 2009 18:28:24 -0700 (PDT)
Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 60CF23A677C for <hybi@ietf.org>; Mon, 13 Apr 2009 18:28:24 -0700 (PDT)
Received: by yw-out-2324.google.com with SMTP id 5so3240755ywh.49 for <hybi@ietf.org>; Mon, 13 Apr 2009 18:29:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.48.20 with SMTP id a20mr14069225ybk.7.1239672575271; Mon, 13 Apr 2009 18:29:35 -0700 (PDT)
In-Reply-To: <Pine.LNX.4.62.0904122350370.10339@hixie.dreamhostps.com>
References: <49DEF171.4080506@mozilla.com> <A3699591-148C-4795-967A-6CDE23FE75F0@apple.com> <Pine.LNX.4.62.0904122230550.10339@hixie.dreamhostps.com> <71289452-5A19-48F4-9819-7FD9747EE9CA@apple.com> <Pine.LNX.4.62.0904122251070.10339@hixie.dreamhostps.com> <1D801D05-C7F1-4DDC-8034-FAA458626F53@apple.com> <Pine.LNX.4.62.0904122350370.10339@hixie.dreamhostps.com>
From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 13 Apr 2009 18:29:20 -0700
Message-ID: <63df84f0904131829j5bc1b85amf8d24fdd30644f1d@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] Apples and Orangutans
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: Tue, 14 Apr 2009 01:28:25 -0000

On Sun, Apr 12, 2009 at 5:11 PM, Ian Hickson <ian@hixie.ch> wrote:
> Current API:
>
>   socket = new WebSocket('ws://example.com/chat.dcp');
>   socket.onmessage = function (e) {
>     if (e.data != 'DCP') {
>       error('The server mysteriously stopped speaking DCP!');
>       socket.disconnect();
>     }
>     socket.onmesage = chatHandler;
>   }
>   socket.postMessage('DCP');
>
> Explicit API:
>
>   socket = new WebSocket('ws://example.com/chat', 'DCP');
>   socket.onprotocol = function (e) {
>     if (e.data != 'DCP') {
>       error('The server mysteriously stopped speaking DCP!');
>       socket.disconnect();
>     }
>   }
>   socket.onmesage = chatHandler;

I agree with Maciej here. I think having explicit metadata information
regarding which protocol is being transferred is of value. Allowing
people to do the "RightThing" while still letting them do the
"EasyThing that doesn't get in the way of the RightThing" is of even
higher value.

If the API could be something like

socket = new WebSocket('ws://example.com/chat', 'DCP');
socket.onprotocol = chat_handler;

for the people that want checking. And

socket = new WebSocket('ws://example.com/chat');
socket.onprotocol = iKnowWhoImTalkingToAndDontNeedNoStinkingChecking_handler;

for the people that are using their own home-brewed protocol. This
could use some magic value as the type (a'la
"application/octet-stream") or leave out the protocol indicator
entirely.

I don't have an opinion on if this type should be transferred to the
server which would be responsible for the checking, or if the type is
transferred to the client which would do the checking, or if its
transferred both ways for added goodness.

But the point is that the type is transferred at a specified location.
And IMHO that specified location should be separated from other fields
with other purposes. My understanding is that the path is intended to
allow for several websocket services from the same origin, thus I
would prefer if the protocol is separate from the path.

/ Jonas