Smarter Clients Via ReverseHTTP and WebSockets

igrigorik writes "Most web applications are built with the assumption that the client / browser is 'dumb,' which places all the scalability requirements and load on the server. We've built a number of crutches in the form of Cache headers, ETags, and accelerators, but none has fundamentally solved the problem. As a thought experiment: what if the browser also contained a Web server? A look at some of the emerging trends and solutions: HTML 5 WebSocket API and ReverseHTTP."

Re:Perhaps I just don't understand TFA, but...

[Locklin]

Scenario: I'm pointing my browser at a server I run at home. In my browser I run a small webserver that can access a commandshell. Cool, now I can work from home despite a firewall and lack of software :) Sorry dear sysadmin, your firewall just got a few new holes in it :)

I used to do that on my University's network with a reverse SSH tunnel. You could even do it over port 80 if they blocked outgoing 22. The only issue would be if you could install that webserver on a locked-down machine that has no SSH client.

Re:Connection, yes. Server, no.

[raddan]

I don't think you're going to see people give up NATs easily. NAT is a bona fide security feature, not just a consequence of having a LAN. This is the same thing that makes detecting bad segmentation faults possible in an operating system, and from that perspective, a separate address space is very desirable.

Any kind of 'fundamental change' that happens on the Internet needs to accept that NATs part of good architecture. You really want your toaster on the same address space as your Cray?

Re:Problem?

[digsbo]

The problem is that this is not funny, but painfully true. The problems of cross-platform client GUIs are all being solved again, but on top of several new layers of APIs with little value-add and a big performance hit. If you want to write a client-server app, please do so! Stop trying to make the browser the cross-platform widget toolkit.

I've seen good developers try to use UDP instead of TCP to save a few bytes of overhead, and they failed. How will web developers without any concept of network programming theory manage to recreate (or even use) a persistent, robust, and high-performance connection over HTTP? I doubt it will work well. We'll end up with more kludge layers between the browser, OS, browser plug-ins, etc....

Re:Problem?

[radish]

That just shows he doesn't know what he's doing. The exact same little python script could have generated a simple web form and submitted to the DB.