Re: [hybi] web socket protocol in "last call"?

[Ian Hickson <[e-mail]>]

On Wed, 28 Oct 2009, Salvatore Loreto wrote:
> Ian Hickson wrote:
> > 
> > There's a couple of e-mails from earlier today that I haven't yet 
> > considered, but other than that, I've read and considered all the 
> > e-mails to this list, and provided detailed reasons for rejecting any 
> > proposals I've not adopted. If I missed one, please let me know.
> 
> actually in the IETF process one of the main reason to accept or reject 
> a proposal/issue/"request to change something" is based on *"rough 
> consensus"* reached among people involved in the mailing list 
> discussion, especially when the reason for accepting or rejecting are 
> based more on philosophical then technical issues.

I must admit to being more interested in technical soundness than 
consensus. However, if we are to base things on consensus, then we need an 
objective definition of consensus, so that it can be determined when we do 
or do not have consensus. Is there such a definition?


> The decision to adopt or not a proposal should come from the consensus 
> and not from the decision of a single person. I am sorry to notice, 
> following the ml discussion, that a lot of the proposals have been 
> discarded for philosophical reasons even if the majority of the people 
> in the ml were in favour. I am not saying that you should adopt them 
> straight, but only that you should keep open the discussion on 
> controversial issues and seek a sort of consensus, among people involved 
> in the discussion, on how to solve them

I thought that's what I was doing: responding to proposals with counter 
proposals, evaluating arguments on technical merit, and taking part in the 
continuing debates. Surely you are not suggesting that anybody has been 
preventing anyone from continuing the discussions?


On Wed, 28 Oct 2009, Infinity Linden (Meadhbh Hamrick) wrote:
>
> wow. WS is in last call? not being able to continue work on putting 
> something like RHTTP or BWTP over WS is a bit of a deal-breaker for me.

Nobody is suggesting stopping work on anything, as far as I am aware.


> i guess there's also no reason now to meet at apachecon next week about 
> WS. i mean, why bother meeting about something you can't change?

"Last call" is not the end of the process. If you have feedback, please 
don't hesitate to send it.


> WS is essentially unusable for me in it's current form. or rather, i 
> could use it, but why? my use case of establishing reverse 
> request-response semantic recognizable by intermediaries that supports 
> channel multiplexing is possible over WS, but then again, it's also 
> possible by extending HTTP, so why not just do that?

Could you elaborate on your use case?

WebSocket is a better substrate for bidirectional communication than HTTP 
in some specific ways: the latency involved in having to establish new TCP 
connections for each HTTP message is non-existent in WebSocket, the 
overhead of HTTP headers with each request (leading to 1000:1 
overhead:data ratios when sending simple messages like "the user pressed 
'a'") is minimised in WebSocket (the kilobytes of headers overhead in HTTP 
is reduced to two bytes in WebSocket), and the difficulties on the 
server-side of associating outgoing connections with incoming connections 
is removed (there's only one TCP connection in WebSocket).

What problems are you having that WebSocket _doesn't_ solve, or prevents 
you from solving?


On Wed, 28 Oct 2009, Infinity Linden (Meadhbh Hamrick) wrote:
> 
> HyBi has a few people who are interested primarily in (bidirectional) 
> HTTP as a substrate for other application layer protocols. is there a 
> similar constituency in WHATWG? (probably should have asked this way 
> earlier.) in other words, while i think pushing HTML+JPEG over HTTP is 
> cool and about the only use case browser vendors are going to worry 
> about; my personal interest is in pushing xml, json, and random weird 
> BASE64 encoded binary blobs with metadata over the connection.

As far as I can tell, the use case of sending occasional large blobs of 
data to the server from the client is already addressed by HTTP (via 
XMLHttpRequest on the client), so I don't think there's a need for Web 
browsers to implement new protocols to support it. However, I have no 
objection to the working group developing a technology to support this.


On Thu, 29 Oct 2009, Greg Wilkins wrote:
> 
> I completely agree with this sentiment.  WS is usable, but provides no 
> significant benefit over HTTP other than a warm philosophical feeling 
> that you are not abusing HTTP, is a little more byte efficient and 
> marginally better latency.

Reducing kilobytes of data to 2 bytes is more than "a little more byte 
efficient", and reducing latency from 150ms (TCP round trip to set up the 
connection plus a packet for the message) to 50ms (just the packet for the 
message) is far more than marginal. In fact, these two factors alone are 
enough to make WebSocket seriously interesting to Google.


> But it is not going to scale for my use-cases because of the connection 
> bloat.

It halves the number of connections relative to current solutions. I would 
hardly characterise one connection per user as bloat -- it's the same 
model used by IMAP, SSH, and IRC, to name but three protocols I'm using 
right now. 


> It's going to break all the load balancers I work with and the SSL 
> offloaders and most other network infrastructure.

Could you elaborate on what requirements your load balancers and SSL 
offloaders have which, if addressed, would lead to WebSocket working with 
them to your satisfaction?


> Failing consensus on the protocol, I would have really liked the 
> opportunity of having a service provider API in the browser - so I could 
> intercept standard ws API and transport it over something that would 
> work my use-cases, or inserting layers between app API and transport.

I don't think that's impossible -- as with any browser feature, the first 
step is convincing browser vendors that they should implement such a 
feature. Generally I work the other way around -- I listen to browser 
vendors, then spec what they say they want to implement. But sometimes 
it's possible to convince browser vendors that they want to implement 
something. However, it doesn't matter what the Hybi group does -- browser 
vendors don't automatically implement something the IETF or W3C invent. 
They have to want to implement it.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'