Re: [hybi] [Uri-review] ws: and wss: schemes

Jamie Lokier <jamie@shareable.org> Thu, 10 September 2009 12:45 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 854163A6844; Thu, 10 Sep 2009 05:45:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.941
X-Spam-Level:
X-Spam-Status: No, score=-2.941 tagged_above=-999 required=5 tests=[AWL=-2.131, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3]
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 B2gi8bH+3T9U; Thu, 10 Sep 2009 05:45:51 -0700 (PDT)
Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id AF8613A686A; Thu, 10 Sep 2009 05:45:51 -0700 (PDT)
Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from <jamie@shareable.org>) id 1Mlj2Y-0000fd-2e; Thu, 10 Sep 2009 13:46:18 +0100
Date: Thu, 10 Sep 2009 13:46:18 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Křištof Želechovski <giecrilj@stegny.2a.pl>
Message-ID: <20090910124618.GB32178@shareable.org>
References: <Pine.LNX.4.62.0908070531430.28566@hixie.dreamhostps.com> <1249651007.25446.8934.camel@dbooth-laptop> <0B450D619CC0486E8BD51C31FBA214AD@POCZTOWIEC> <20090812021926.GC19298@shareable.org> <AB9A0CF094F04D39BC7DC5DEAFF7FC1C@POCZTOWIEC> <4AA8A2CE.3000801@it.aoyama.ac.jp> <34660A8503164BE88641374ADF2BF1A3@POCZTOWIEC>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <34660A8503164BE88641374ADF2BF1A3@POCZTOWIEC>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: 'David Booth' <david@dbooth.org>, hybi@ietf.org, uri-review@ietf.org, uri@w3.org
Subject: Re: [hybi] [Uri-review] ws: and wss: schemes
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: Thu, 10 Sep 2009 12:45:52 -0000

Křištof Želechovski wrote:
> I think the idea to use Web Sockets on the server is void; the server can
> use TCP/IP at will.

Nice theory.  I believe you have correctly described the intentions of
the WebSockets protocol proposers (as I understand them), and that the
theory is denying reality.

It's wrong.  A server cannot use TCP/IP at will in two scenarios:

1. A server must use WebSockets if it's accessing services which a
   different provider has only made available via WebSockets, due to
   the provider only intending the service for web browsers.

   For example, at one time something like Google Maps' image back-end
   would fit this pattern: only intended for one web application, but
   actually used by various third parties because it's useful.

   Judging by the modern trend to 'mashups', expect this practice to
   become widespread

2. When a service is provided by WebSockets to support a web browser,
   and a requirement emerges to provide the same service to other programs.

   Many implementors will use the path of least resistance, which is
   to continue offering using the service over WebSockets in the new
   context, and require the clients to use generic non-browser
   WebSockets code.  That is simpler than specifying and implementing
   a second protocol for the same service.

   For examples of where this has happened before, see SOAP.  It runs
   over HTTP simply to reuse deployed and well understood code and
   infrastructure.  In principle it could run over raw TCP/IP or a
   simple framing protocol, but that's not done in practice.

   Expect the same to occur with WebSockets if it is widely used by web
   applications.  If only because of familiarity and duplication avoidance.

-- Jamie