- From: Philipp Serafin <phil127@gmail.com>
- Date: Fri, 20 Jun 2008 20:16:18 +0200
On Fri, Jun 20, 2008 at 7:31 PM, Frode B?rli <frode at seria.no> wrote:
> If the socket is created like this: var socket = new
> WebSocket("http://www.example.com/chatserver.xsocket");
>
> Then the .xsocket file is an XML file specifying exactly how the
> WebSocket should connect to the server and perhaps any restrictions on
> the connections? It would be similar to including a script from a
> server, but this would have the following benefits:
>
> 1. The chatserver.xsocket-file could be dynamically generated,
> allowing many things that we may not think about today.
> 2. It would be suitable for shared servers.
> 3. It would allow for example Yahoo! to create services that you can
> connect to simply by doing new
> WebSocket("http://www.yahoo.com/services/search.xsocket")
> 4. To load balance, the url could redirect the connecting user to
> another xsocket file on another server perhaps?
>
> Frode
This sounds like a really good idea. You could even expand this and
use raw TCP connections, then have the xsocket file, for example,
specify a block of data the browser has to send over the new
connection before control is passed to the web application.
That way web hosters could use their own method of mapping customers
to persistent connection. Owners of dedicated servers could leave the
field blank and have all the flexibillity of a raw connection.
Web applications could still easily ported from one system to the
other, because the file would be processed transparently.
The only problem I see is getting the allowed domains right, the
xsocket file can point to. On the one hand, you may want a dedicated
machine for the persistent connections if you run a very popular
service and anticipate many connections at once. On the other hand,
you don't want an evil site getting access to your service using their
own xsocket file.
Received on Friday, 20 June 2008 11:16:18 UTC