Re: [hybi] #1: HTTP Compliance

[Greg Wilkins <[e-mail]>]

On 22 July 2010 16:32, Ian Hickson <[e-mail]> wrote:

> > I disagree completely -- there is going to be a web server involved in
> > delivering the web application, and I think the more usual scenario is
> > that web server also implements the WebSocket server.  Why would someone
> > prefer to deploy two servers rather than one, except in the case where
> > their web server doesn't yet support WebSocket?  If this protocol is
> > successful, over time that will drop to 0.
>
> I see no advantage in the common case to using the same software for both.
> It's far easier to just host them separately.
>

The evidence in this WG is that many server side developers see great
benefit in using a single server for both HTTP and Websocket.

The reason is that a websocket based application is a WEB application that
will be combination of HTTP served resources (markup, images, css,
javascript) interacting with websocket received/served resources
(messages).  Many of these applications will have fallback transports that
will use HTTP when websocket is not available.

It is highly desirable to avoid multiple instances of business logic for a
single client, thus it is highly desirable to have a single application
context handle both HTTP and websocket transactions for the same client.
Having multiple servers is just a recipe for complex applications suffering
from race conditions or needing the extra expense of putting more operations
through a transactional mechanism (DB, JMX etc.).



> Why don't people use the same software for HTTP and DNS? Or IMAP and SMTP?
> Or IRC and FTP? Why would they act differently for HTTP and WebSocket?


Applications that combine mail and web applications often do run protocols
like SMTP in the same process as the web server.   Ditto for IRC, XMPP etc.

cheers