> (Indeed, I'll be surprised if server-driven dynamism ever goes anywhere.
> It puts the processing requirements at the wrong end, requiring the
> server to do the processing for all of its clients. That's a nasty
> bottleneck for most applications. Regardless of the exact API chosen,
> I expect most dynamic processing to happen on the client in some
> fashion, just because clients usually have far more horsepower to
> spare.)
Get ready to be surprised, then, because I see no other way to provide a
multi-user environment. There has to be a network of servers which would
update clients based on the changes made by other clients. See IRC.
Obviously, since the server needs to be concentrating on the job of
change coordination and distribution, it should expect that the browser
is sophisticated enough to do change integration and rendering. We have
to offload as much as we can, but some things can't be offloaded without
creating other problems.
BTW: Assuming that the Server is the bottleneck is not very thourough.
What if you have a Supercomputer rendering spaces, and a 100MBit Ethernet
distributing it to a bunch of low throughput PCs which could do no more
than display the view. It would work. If you then cut the Ethernet to
10MBits, and it stops working, it's not the Server that's the bottleneck.
You could then replace the PCs with high speed workstations, and the
bottleneck would still be the Ethernet. Bottlenecks occur everywhere.
It's a big system.
---
Andrew C. Esh mailto:[email protected]
Computer Network Technology [email protected] (finger for PGP key)
6500 Wedgwood Road 612.550.8000 (main)
Maple Grove MN 55311 612.550.8229 (direct)
<A HREF="http://www.mtn.org/~andrewes">ACE Home Page</A>