Charles,
You state the need for real asynchronous communications between server
and client, and you are absolutely right that it is critically
important to have that for real web applications. However, I believe
it would be shortsighted to solve the problem by creating an API to
make TCP connections from within a web application. Aside from
security concerns, there are three major issues I see with that
solution.
Firstly, it exposes a very low level protocol to the programmer of the
web application, forcing them to code higher-level protocols themselves
from within ECMAScript. While certainly this would allow a high degree
of freedom on web application programmers, it would also put an
unnecessary burden on them when a higher-level, simpler solution would
have sufficed.
Secondly, it probably wouldn't work in all cases -- for example clients
that require the use of a proxy server to access the network, or are
behind a firewall that allows only HTTP connections.
Finally, it assumes that TCP connections are the best way to get data
from the server to the client. While this is almost certainly the case
for desktop computers, it may not be a good assumption for mobile
terminals. Operator networks might in the future have built-in
eventing protocols that can more efficiently dispatch data
asynchronously to client devices without the need for the overhead of
maintaining many virtually unused TCP connections.
Luckily, there is already a proposed solution, part of which is
included in the Web Applications draft. In section 9.1 of the draft
(http://www.whatwg.org/specs/web-apps/current-work/#server-sent) a
framework is proposed that allows for asynchronous communications from
server to client by way of server-sent DOM events. Basically, the
server-sent DOM events would allow a web applications programmer to
make an API call to register for a remote event located at a particular
URI (on a server), and to subsequently receive DOM events when they
arrive from that server. The details of the low-level connection are
left up to the user agent and the server to manage, rather than
requiring scripted code to handle them. And, while the section in the
current draft shows examples using event sources at HTTP URIs, it
leaves the door open for them to be located at other URIs as well.
Do you see any reason why you couldn't achieve everything you needed
using this method rather than by having low-level TCP connections
exposed in the API?
I did notice that, while the server-sent DOM events described in the
current draft address by first two concerns, the third one has not been
specifically handled, although I suppose it is left open by allowing
other non-HTTP protocols.
However, since ideally the same web application code would work on all
platforms and networks, it would be better if there was a way to
negotiate the low-level transport between the client and server rather
than have it hard-coded into the script. For example, a web
application showing real-time stock prices wants to get an event stream
that updates the stock prices from a server, let's say stockserver.org.
For most desktop clients, using the event-source URI
"http://stockserver.org/stockprice" would be fine. However, a mobile
client using the same page would waste a (relatively) lot of bandwidth
just by keeping that HTTP connection alive, and it so happens that the
particular (and fictitious) mobile network has low-level support for
SIP events (could just as easily be XMPP or perhaps even SMS or
WAP-Push). Therefore, for that client it would be advantageous to use
a URI such as "sip:stockserver.org;subscribe?event=stockprice" instead
of HTTP since there would be significantly less network overhead that
way. However, it is undesirable for the web application developer to
have to provide a separate version of the page for the mobile user on a
SIP-capable network, so it would be advantageous to have an option for
the server and client to negotiate the low-level transport. Perhaps
this could be done using an extension to the proposed baseline
HTTP-based implementation?
Ian, perhaps we could add to section 9.1 a header that can be sent by
the user agent along with the initial request to the event-source URI
that specified a list of event protocols that the user agent supports?
Perhaps something like "capabilities"? Then, the server, knowing what
the client support was, would have the option of returning a 3xx
redirect to the other protocol URI instead of opening the event stream?
If for some reason the user agent was unable to establish the event
stream using the new protocol, it could re-contact the server but
remove the failed protocol from it's list of capabilities. This seems
to me to be the least obstrusive way of adding basic protocol
negotiation to the server-sent DOM events -- do you see any reason why
it shouldn't be in there?
josh.
On May 26, 2005, at 3:08 PM, Charles Iliya Krempeaux wrote:
> Hello,
>
> (Please excuse me if this has already been discussed. I'm still
> working my way through the mailing list archive. Also, I hope I'm not
> out of place by just interjecting myself.)
>
> Are there any plans to add an API to create TCP connections?
>
> IMO, this is very necessary for creating "web applications". And it
> would be unfortunate if it wasn't included.
>
> Right now, there seems to be a new fad revolving around
> XmlHttpRequest. It has been nicknamed AJAX by many. And heralded as
> a means of asynchronous communication for the Web. However, AJAX only
> gives the illusion of asynchronous communication between the server
> and client. The client is polling the server. And often a new TCP
> connection is created (and later tore down) each time the server is
> polled. (Which, IMO, is bad.)
>
> The nice thing about XmlHttpRequest is that it makes it so you can
> "update" a webpage without having to reload it. Which improves
> usability. However, because of the polling, performance is adversely
> affected. Not to mention that polling is not the optimal mode of
> communication.
>
> One could come up with a new protocol for asynchronous communication.
> (Maybe as something to accompany HTTP. Or maybe even as an extension
> to it -- HTTP 1.2?) Which may solve this problem. But other
> "problems" could arise in the future. It would be good to provide
> developers (of web applications) the building blocks to solve a wider
> set of problems. And to me, I think having an API to create TCP
> connection is one of these building blocks.
>
> Some might say that letting the client create general TCP connects
> would bring up all sorts of security concerns. However, I think these
> security concerns can be dealt with by making it so the API would only
> allow the client to create a TCP connection to the "host" that the
> client -- the webpage (or web application) -- came from.
>
> Or, alternatively, we could allow the host that the webpage (or web
> application) came from to specify a list of domains (or IP addresses)
> that clients could connect to. (Of course, there would be
> restrictions on this. The hosts in that list would need to "allow"
> the original host to do this. A mechanism for this would need to be
> created.)
>
> There could even be other restrictions. For example, a host could
> specify what ports it allows webpages (and web applications) to
> connnect to.
>
>
> So,... are there any plans to add an API to create TCP connections?
>
>
>
> See ya
>
> --
> Charles Iliya Krempeaux, B.Sc.
>
> charles @ reptile.ca
> supercanadian @ gmail.com
> _______________________________________________________________________
> ____
> Wikibooks, Free Open-Content Books
> http://wikibooks.org/