[whatwg] WebSocket support in HTML5

[Shannon]

Richard's Hotmail wrote:
>  
> 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.
>  
> 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.
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:

* Java raises a security exception unless the user authorises the socket 
using an ugly and confusing popup security dialog
* 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".

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".

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.

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.

Other than that it behaves as an asynchronous binary TCP socket. What 
exactly are you concerned about?

Shannon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080922/66208e55/attachment-0001.htm>