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

[Jamie Lokier <[e-mail]>]

Ian Hickson wrote:
> The Web Socket API is here:
> 
>    http://dev.w3.org/html5/websockets/
> 
> I don't really see any sane way to have the API itself do some sort of 
> fallback, especially not to HTTP.

Ah, that'll be why you didn't respond to discussions about that :-)

> On Sat, 8 Aug 2009, Jamie Lokier wrote:
> > Tunnelling WebSocket two-way communications over standard HTTP messages, 
> > using any of the methods used for that, would be natural and probably 
> > useful behaviour.
> 
> That is a radically different system on the server-side.

Yes.

> While authors should naturally be allowed to do that using XHR if
> they desire,

All authors can just use the WebSocket API.

When running on older browsers they'll use a Javascript
backward-compatibility package which emulates WebSocket, using some
other mechanism underneath.

> forcing servers into having that kind of fallback behaviour
> radically increases the complexity of a server-side deployment.

Not much.  The art of good software development is to hide the
complexity where it has to exist.

"apt-get install ws2http".  Problem solved.

> A Web Socket protocol implementation can be written in 100 lines of
> Perl or so;

If using libraries, 5 lines of Perl.

If avoiding libraries, you can, barely, but:

   - Trust me there will be bugs, if only in mishandling UTF-8.

   - Anyone doing that values simplicity over performance.
     Which is great, see next section.

> having to add to that some sort of HTTP server or CGI scripting
> would make things significantly more complicated.

No, it's very simple to the person writing 100 lines of Perl.

They'll install a WebSocket <-> HTTP proxy which is written by
professionals in C.  "apt-get install ws2http".

On the client side, they'll use a Javascript file which emulates
WebSocket (when necessary), using HTTP which works with ws2http.

Job done.  Johnny's interactive Tic-Tac-Toe (his very first web app!)
will work over the HTTP internet with *no changes at all* except
minimal configuration.

> On Sun, 9 Aug 2009, David Booth wrote:
> > I can't see that as a significant issue, as there is only a trivial 
> > difference between dispatching based on the string prefix 
> > "http://wss.example/" and the string prefix "wss:".  Both are simple, 
> > constant strings and both are equally "magic": they cause agent to 
> > attempt the WSS protocol.
> 
> I don't understand how one would reuse the http: scheme in this way in 
> order to connect to 'example.com' as both an HTTP server and a Web Socket 
> server.

The implication is that it's context dependent - you know you're
making a WebSockets connection - and the prefix would serve much the
same role as URIs do for XML namespaces.

But I must agree that http://www.example/my.domain.org/path/to/service
would be profoundly ugly and pointless.

On the other hand, http://my.domain.org/path/to/service
would be very nice if that Just Worked.

That is, if WebSockets connected and did a standardised and safe
negotiation over HTTP to your own site's URL, and acquired a
WebSockets connection that way.  No need for the ws: prefix!

That would be nice because it leaves open the option to do drop down
automatically to something else if the WebSockets negotiation fails.
(Automatically in the WebSockets implementation, that is, without the
app author having to care).

> > The point is that a prefix like "http://wss.example/" gives agents that 
> > do not know the WSS protocol the possibility of doing something useful 
> > with the URI, by falling back to the HTTP protocol, whereas if a prefix 
> > like "wss:" were used those same agents would have to reject it 
> > entirely.
> 
> UAs that don't support Web Socket are going to have failed long before 
> they see the URI, since they don't support the API either.

They'll acquire a Javascript emulation of it, if that's technically possible.

> I don't understand why we would even want a spider to attempt to connect 
> to a Web Socket server. How would it know what application-level protocol 
> to use? How would it expose this information to the user?

Spiders will follow any text that looks like a URL.  Even comments.
You might not _want_ them to, but they will try anyway, because they
and their users benefit from serendipitous discovery.

It's not about what _we_ want them to do.  It's about what they will
do given a chance.

> On Wed, 12 Aug 2009, Greg Wilkins wrote:
> > The ws protocol has been designed in respect to a single proposed 
> > javascript API to run within a browser.
> > 
> > There are many many uses for bidirectional web which go beyond that 
> > simple restricted example.
> 
> For those purposes, we already have TCP/IP, no?

Because WebSockets isn't _that_ simple on the server, especially with
things layered on top, there will be frameworks to make it easier on
the server side.  Before you know it, that will be more familiar for a
lot of people than TCP/IP.  In the same way that people can write
CGI/WSGI now, but would find writing a TCP/IP server difficult.

Presumably you'd like WebSockets to become familiar to large numbers
of web application developers?

With millions of programmers familiar with writing WebSockets code on
browser clients and servers, and good server-side frameworks for
handling it - of course it will be used in non-browser applications,
whether you think it's a good choice or not.

It's not about *us* the experts, it's about everyone else who only has
the time to learn one thing well.  The same people who cut and paste
Javascript and CGI/WSGI code right now - because it works.

> On Wed, 12 Aug 2009, Jamie Lokier wrote:
> >
> > ws:// URLs *will* be entered on web forms at some point, you can count 
> > on it.
> > 
> > Someone will write a web form that says something like "Tell me the 
> > address of a FOOCHAT server to begin your FOOCHAT session", expecting a 
> > ws:// URL to be entered if WebSockets is the protocol to be used.
> 
> Indeed, that's a good reason for having a single URL rather than having 
> multiple fields in the API.

I agree.

Thanks,
-- Jamie