Re: [hybi] Is there a traffic jam?

["Anne van Kesteren" <[e-mail]>]

On Tue, 14 Apr 2009 08:10:37 +0200, Sylvain Hellegouarch <[e-mail]>  
wrote:
> Indeed. I actually wonder in fact if the problem hasn't been addressed  
> the wrong way around. It seems to me that we've had to discuss so far of  
> a protocol that could basically work out for everything. But could it? I  
> guess most people here have at some point implemented various protocols  
> and feel like WS will not be good at supporting any of them without  
> major headaches and hacks.

This hasn't really been demonstrated. Some people feel that what goes over  
the wire should be identifiable as an intrinsic part of the protocol, but  
I'm still out as to why this is important. (I.e. something more than just  
"string" vs "bytes" vs "...".)

One concern that was raised is that library authors might not work  
together to do things in common. However, library authors already work  
together on common things, such as supporting the same query language,  
ways of allowing multiple libraries to be used by a single page, et  
cetera. There's a whole "alliance" based around this.


> The question I have now is, what does precisely stop browsers from  
> offering a raw TCP socket API at the Javascript level?

The same-origin security policy.


> The answer to those so far has been WebSocket but is it the right way?  
> The endless nitpicking of this list should probably be warning enough in  
> my opinion that it might be the wrong path.

It seems to me that the metadata point is endlessly repeated. I'm not sure  
if that should be an indication of "wrong path" or "clearly entrenched".


> Personally I'd rather have a direct TCP socket access from the browser  
> and let organisations decide if they should allow specific ports to be  
> opened. Afterall, tunelling through HTTP might end up with those  
> organisation sniffing traffic and deny HTTP Upgrade anyway.

The closest to raw TCP socket access we can offer is something that looks  
like Web Sockets.


-- 
Anne van Kesteren
http://annevankesteren.nl/