<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Richard's Hotmail wrote:
<blockquote cite="mid:BAY131-DAV959F02AF896D01F23C331FB480@phx.gbl"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2800.1555" name="GENERATOR">
  <style></style>
  <div> </div>
  <div><font face="Arial" size="2">My particular beef is with the
intended WebSocket support, and specifically the restrictive nature of
its implementation. I respectfully, yet forcefully, suggest that the
intended implementation is complete crap and you'd do better to look at
existing Socket support from SUN Java, Adobe Flex, and Microsoft
Silverlight before engraving anything into stone! What we need (and is
a really great idea) is native HTML/JavaScript support for Sockets -
What we don't need is someone re-inventing sockets 'cos they think they
can do it better.</font></div>
  <div> </div>
  <div><font face="Arial" size="2">Anyway I find it difficult to not be
inflammatory so I'll stop now, but please look to the substance of my
complaint (and the original post in comp.lang.JavaScript attached
below) and at least question why it is that you are putting all these
protocol restriction on binary socket support.</font></div>
</blockquote>
It's hard to determine the substance of your complaint. It appears you
don't really understand the Java, Flex or Silverlight implementations.
They are all quite restrictive, just in different ways:<br>
<br>
* Java raises a security exception unless the user authorises the
socket using an ugly and confusing popup security dialog<br>
* Flex and Silverlight requires the remote server or device also run a
webserver (to serve crossdomain.xml). Flex supports connections ONLY to
port numbers higher than 1024. The crossdomain files for each platform
have different filenames and appear to already be partly incompatible
between the two companies, hardly a "standard".<br>
<br>
Both Silverlight and Flash/Flex are fundamentally flawed since they run
on the assumption that a file hosted on port 80 is an authorative
security policy for a whole server. As someone who works in an ISP I
assure you this is an incorrect assumuption. Many ISPs run additional
services on their webserver, such as databases and email, to save rack
hosting costs or for simplicity or security reasons. I would not want
one of our virtual hosting customers authorising web visitors access to
those services. It is also fundamentally flawed to assume services on
ports greater than 1024 are automatically "safe".<br>
<br>
These companies chose convienience over security, which quite frankly
is why their software is so frequently exploited. However that's
between them and their customers, this group deals with standards that
must be acceptable to the web community at large.<br>
<br>
The current approach the HTML spec is taking is that that policy files
are essentially untrustworthy so the service itself must arbitrate
access with a handshake. Most of the details of this handshake are
hidden from the Javascript author so your concerns about complexity
seem unjustified. If you are worried about the complexity of
implementing the server end of the service I can't see why, it's about
3-6 lines of output and some reasonably straight-forward text parsing.
It could easily be done with a wrapper for existing services.<br>
<br>
Other than that it behaves as an asynchronous binary TCP socket. What
exactly are you concerned about?<br>
<br>
Shannon<br>
<br>
</body>
</html>