[whatwg] web-apps - TCPConnection

[Mike Dierken]

> If the browser had an HTTP daemon built-in, 
> would that work?
> 
> No, since you can't guarentee that incoming connections will connect (e.g.

> because you are behind NAT with no port forwarding, a very common case).
If the client initiated the connection, then the roles were reversed, that
would mirror the TCPConnection approach.

> 
> Also, requiring that UAs implement HTTP servers, as opposed 
> to just implementing the simple TCPConnection protocol 
> described at the moment, seems like a significantly more 
> expensive way of solving this problem.
A full (i.e. complex) server wouldn't be necessary, just the protocol
parsing.
Implementing the protocol for simple use is straightforward, and bringing in
Apache as a library would be one approach.

> 
> 
> > > Another example would be something like an IM or chat client. All 
> > > the current implementations of that are huge hacks that would be 
> > > much simpler to implement if they could just open a TCP connection 
> > > and send free-form data back and forth.
> >
> > I've implemented IM and chat applications with just HTTP, HTML and 
> > Javascript. In a browser. Without plugins.
> 
> Yes, lots of people have. It would be a lot simpler with a 
> bidirectional asynchronous text-based messaging protocol, though.
>From my perspective, it would be a lot simpler to re-use a working protocol
(HTTP) rather than start over & re-learn all the mistakes of the past.

> 
> 
> > The DOM Event portion of the specification is very similar & more than 
> > sufficient for chat and IM.
> 
> That's one way of receiving messages, but it isn't as good for sending 
> them. Using HTTP to send them requires some acrobatics on the server side.

> Using TCPConnection would just mean one process server side.
How is using HTTP going to require acrobatics on the server side? I must be
misunderstanding what you are thinking, because there are dozens of
implementation of HTTP servers.

> 
> 
> > It's unfortunate that port 80 would be needed to 'tunnel out', but I 
> > realize that's the situation most people are in. But I really recommend 
> > that a port 80 outbound tunnel use the protocol assigned to that port - 
> > via the HTTP Upgrade header.
> 
> That would require that the Web author implement HTTP on his side (or at 
> least a simple version of an HTTP server) which seems like undue work. 
My opinion is that 'implement HTTP' means 'reading and parse a text stream'
- not undue work, even for a 'Web author'.

> What would the advantage be? We're not connecting to an HTTP server. 
> Upgrade makes sense if you are upgrading from HTTP to something, but here 
> we're not expecting HTTP to ever be used over the connection.
The point is that since you want to initiate a connection on port 80, then
you should use the protocol assigned to that port. It has specified
mechanisms to upgrade to a proprietary protocol - it doesn't cost a whole
heck of a lot & you wind up being standards compliant.

> 
> 
> > > We don't want to require that authors implement an entire HTTP server 
> > > just to be able to switch to a proprietary protocol.
> >
> > Nobody has suggested requiring an entire server. Two messages is all it 
> > takes. Not only does HTTP scale up well, it scales down too.
> 
> No, because you have to implement correct handling of everything _other_ 
> than Upgrade: as well, even if it is to return "Not Supported" each time. 
Good point.

> You have to parse headers, etc. Nobody is going to actually bother to 
> correctly implement that, and if they don't, what's the point in 
> pretending that they do? It would just make matters worse, with obscure 
> per-server/client pair bugs for browsers to work around.
Browsers don't need to work around a broken server, regardless of which spec
the server author didn't follow.