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

[Křištof Želechovski <[e-mail]>]

AIUI, in order to provide a service over WebSockets, you have to implement
it in raw stream first.  This stream, once implemented, can run quite
happily under tcpd, and the WebSockets shim is only a wrapper.  So there is
one protocol and one implementation thereof, only exposed over two different
transport channels.
The situation with SOAP is rather different, as it relies on various
HTTPisms to work.
IMHO,
Chris

-----Original Message-----
From: Jamie Lokier [mailto:[e-mail]] 
Sent: Thursday, September 10, 2009 2:46 PM
To: Křištof Želechovski
Cc: 'Martin J. Dürst'; [e-mail]; [e-mail]; [e-mail];
'David Booth'
Subject: Re: [hybi] [Uri-review] ws: and wss: schemes

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:

[snip, perhaps]

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