This is not a layer 7 problem, its a layer 1 problem. Get your ISP to provide unfiltered nearly-synchronous connectivity with pervasive ipv6 (no-nat) and then we can start getting rid of the client server model.
It's Time for Server-Side Browsers
21–30 of 45 posts
Re: It's Time for Server-Side Browsers
#22Or we could stop treating the HTTP/browser combination as an application delivery platform. It's unpopular here, but it's becoming exceptionally obvious as the correct choice.
The term "exceptionally obvious" might be over-stating the case a bit. Please could you expand on why you think that
Please could you expand on why you think that
In 1993, I was the only person I knew with a web browser. 18 years later, we have applied hack after hack to make it into an "application platform." And it's still the same old thing.. a way to deliver hypertext pages to people.
If you want to allow people to sync their files, share large popular binaries or listen to the perfect mix of music, you don't do it over HTTP. Not because you don't understand HTTP, but because you do.
Re: It's Time for Server-Side Browsers
#23Earlier quoted context omitted.
Way before that — the X window system.
It's not seamless though, and that makes it a very different idea. He's talking about it working at the same level as a browser where it sees if you have HTML5, and if not falls back to flash, dynamically. I can't imagine it being a high priority - fiddly, low return, creates huge performance issues. Lots of basic problems - you don't want someone supplying input to a game over a (latent) network. You don't want to b…
You can implement this (somewhat wastefully) using VirtualBox and VNC.
Re: It's Time for Server-Side Browsers
#24Or we could stop treating the HTTP/browser combination as an application delivery platform. It's unpopular here, but it's becoming exceptionally obvious as the correct choice.
How should we treat it?
What is the alternative application delivery platform?
Where is it becoming exceptionally obvious?
Tks in advance.
Re: It's Time for Server-Side Browsers
#25Earlier quoted context omitted.
Presumably he/she envisions a Facebook/BitTorrent hybrid with content replicated across the social graph. You'd get drafted into storing images for some subset of the intersection of your social graph and several others, and the rest of your images would be served by someone(s) with whom your social graph intersects. Presumably invitations would be via e-mail, or, if you wanted to be even more decentralized, QR code.
... Which assumes people keep their machines running 24/7 on unlimited data connections. It's a nice idea from a tech point of view, but for the life of me I cannot see how it's superior to what we already have.
Well, except some degree of redundancy would be built in to the storage scheme á la BitTorrent.
As far as data volume, I've got to imagine the data usage per user would be significantly less than BitTorrent.
The desirable aspect of this system is obvious - the only people who see your data are people who've seen a QR code from someone in your social graph - your FaceTorrent profile will never, ever be indexed by Google.
Re: It's Time for Server-Side Browsers
#26Earlier quoted context omitted.
The term "exceptionally obvious" might be over-stating the case a bit. Please could you expand on why you think that
Please could you expand on why you think that In 1993, I was the only person I knew with a web browser. 18 years later, we have applied hack after hack to make it into an "application platform." And it's still the same old thing.. a way to deliver hypertext pages to people. If you want to allow people to sync their files, share large popular binaries or listen to the perfect mix of music, you don't do it over HTTP. N…
It's possible that the reason the web's still "the same old thing" is because it has been proven an effective platform for distributing services and is, _in practice_, a system that's extremely scalable and evolvable. Infact, it's so successful there's nothing to compare it to - which means no value judgement or comparison is at all "obvious".
HTTP is also extensible (by design), which has lead to stuff like WebDAV and the like. Stuff that is used large scale, over the web. So the web is not 'just' HTTP.
There's deliberate trade-offs in the web's architecture which means, unfortunately, you can keep coming up with edge-case applications which are challenging (although often not impossible) to implement using web technology. The reality is that a large majority of applications are information-centric, are distributed in nature, need to evolve over extended periods of time, and therefore benefit _greatly_ from the trade-offs that the web has made.
The web's not perfect but it's evolving and - importantly - it doesn't have the benefit of being completely fictitious and living inside the mind of a jilted, chippy geek. No offense. ;)
Re: It's Time for Server-Side Browsers
#27An interesting tangent to this discussion is OTOY (http://www.otoy.com/), where your browser simply functions as a display and input device; all the heavy lifting of 3D rendering and game logic is processed server-side.
Re: It's Time for Server-Side Browsers
#28This is not a layer 7 problem, its a layer 1 problem. Get your ISP to provide unfiltered nearly-synchronous connectivity with pervasive ipv6 (no-nat) and then we can start getting rid of the client server model.
That's at least layer 2 (in the IP model) or layer 3 (in the OSI model). /nitpick
Re: It's Time for Server-Side Browsers
#29Making browsers servers as well makes much more sense. At least allowing communication that is peer to peer. This would dramatically reduce network costs for the application owner.
There is a Proposal for peer to peer browser communication. See: http://www.whatwg.org/specs/web-apps/current-work/multipage/...
Re: It's Time for Server-Side Browsers
#30I built a proof of concept that sort of does this:
https://github.com/shazow/relay.js
Someone hosts a hub which just acts as a dumb message-passing relay between browsers via websockets. When a server connects, it sets a code payload. Then when a client connects to the same hub and requests the server, it receives the code payload and a streaming 2-way connection to the server.
There's a few live examples like a collaborative whiteboard in about ~40 lines of js.