h a l f b a k e r yLike gliding backwards through porridge.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
I'm convinced that web apps are all that will matter for desktop software in a few years, stuff like Gmail and Writely and the like.
These web apps with desktop-app-like interactivity require very large bandwidth to be adequate. (If Gmail or Writely doesn't respond nearly instantly, it's pretty lame)
If
the company fills the demand for more and more bandwidth, it's probably going to get more and more commercial.
This can be avoided if users or fans of the web app provide the bandwidth.
So my idea is some software that will allow anybody to provide bandwidth for a web app if they want to.
So if you want to donate more bandwidth for Writely, you would just download this program and run it on your computer.
It would work peer-to-peer. In other words, all the instances of this distributed web hosting program installed all around the world would communicate their connection speeds, dynamic IP addresses, etc to each other. And they would all negotiate the load balancing on a peer basis.
The best part though is that it gives any amature the possibility to launch a high-interactivity web app without all the money google has behind it.
Different client/server Configurations
http://en.wikipedia.org/wiki/Thin_client
From the Wikipedia. [reensure, Aug 24 2006]
[link]
|
| |
What these apps need is low latency (getting data quickly), not necessarily high bandwidth (getting a lot of data). |
|
| |
Design for fast reactions is a mix between moving functionality into the browser and making good decisions about service architecture. That last part is complicated. |
|
| |
[Jutta] makes exactly my point. We had snappy interfaces on 286 machines seventeen years ago. |
|
| |
Shove your interface to the client and try to move an absolute minimum of data back and forth with the server. |
|
| |
After you've overcome the disadvantages of web based apps (reliability, speed etc), what advantages do you get? |
|
| |
[xav]A web based app is easier to control piracy on. If you keep the app on your server, and only lease use of it, no one can copy it and distribute it to non paying users. |
|
| |
Given web services, akamai, compute servers,hosting companies et.al I'm not sure there is a new idea here |
|
| |
piracy tho a real problem does not seem to have hurt mr gates or mr jobs or any one of the hundreds of other million and billionaires out there. |
|
| |
I Dont really see how your problems have much to do with your solution here, but im not a computer genius either. |
|
| |
Youve not considered one of the biggest issues with web based apps, the fact that they only work well on the web. I would like to be able to work even when my cable provider is having an issue, when you release control of your productivity to a third party you are at their mercy, this could be very bad for business |
|
| |
Beyond the already-mentioned problems with this idea, there are additional technical and bussiness issues that would prohibit its adoption. |
|
| |
In any application where the bandwidth would be sufficiently difficult enough to cover, as to warrant looking into a solution like this, it would be unfeasable to expect each client providing bandwidth for the app to hold enough data to be useful. If there is enough data to need this kind of bandwidth-saving idea, there is too much data for any one client to have at a given time. This means each client could only keep data for a small number of users, the boundries of which is fuzzy for todays social software. |
|
| |
Furthermore, for the use of anything beyond basic storage and retrieval, each of these clients would need to contain the actual server software running on the main hosts. This brings up important intellectual property issues, as each of these clients would hold copyrighted, proprietary software of the company! Such a network of bandwidth and processing saving peers would also add a layer of distribution and asyncronicity to all operations, which has enough overhead to undo any benefits in performance or cost savings for all parties involved. Even in apps where the peers could function solely in a storage fashion, their operations would be either entirely unpredictable in resulting state or would be subject to long waits or asyncronous error reporting between the host, peers, and clients. |
|
| |
I bet google could figure out how to make it work though.... : ) |
|
| |
they already use 100,000 servers running fairly simple software to power the stuff they do now |
|
| |
the main point of my idea is not for big companies like google, but rather to allow any creative software person to launch a web app with the likes of gmail |
|
| |