Slashdot Mirror
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."
Are you trusting the site you connect to. That is the Active X mentality. If you went to the site then it is OK.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
While I agree with the parent, that accepting incoming connections is a bad thing - it may also be the "killer feature" to implement IPv6. Auto-configuring clients to support incoming connections is inherently difficult in NAT.
> But accepting incoming HTTP connections in the browser is just asking for trouble.
Exactly, transparent caching proxies would seem to solve issue in a simpler and easier to manage way. Then again, providers trying to implement caching proxies that I know of have all abandoned the idea after trying it. Their customers complained to much and it brings all sort of problems with the transactional behavior of an application.
So people do not like caching proxies, why would they like one in their browser ? Why would they like getting content from another user browser instead of from the original source ?
Also, we live in a economy where we try to boost demand. I observed this trend many years ago: The more we go into the future, the less we seem to be concerned about bandwidth. Bandwidth is getting cheaper and cheaper and providers want to sell more bandwidth ;-)
Bandwidth usage is meant to go up anyway so I do not see their concept fly. I mean if we are really concerned about bandwidth that much, let's start by design application properly and use what is already in place (cache, expiry headers, etc.) properly, which is seldom the case in the applications that I have seen.
Everything I write is lies, read between the lines.
What's needed is a "GUI Browser" standard that is meant for C.R.U.D. screens (business screens and forms) instead of what HMTL is: An e-brochure format bent like hell to fit everything else. You can only bend the e-brochure model so far. We don't need "fat clients" really to solve most of the problem, but really just a better GUI browser so that we are not sending over 100,000 lines of version-sensitive JavaScript just to emulate (poorly) a combo-box, data grid, or folder/file outline tree widget. That's like inventing a cell-phone just to call your next-door neighbor.
Table-ized A.I.
Does this mean we're finally getting proper sockets, instead of having to do everything through HTTP requests? I've been advocating this for years ...
Yes. And no. The HTML5 spec includes a sockets-like API. However, it's intentionally crippled so that you can't use it to communicate with an application that hasn't been specifically enabled to communicate with it (i.e. it uses its own handshake protocol to ensure it's talking to a system that's designed to talk to it).