Stefano Mazzocchi wrote:
Ross Gardler wrote:
... a rich client requires higher bandwidth.
This argument absolutely bogus.
Google Maps, for example, is a way richer client than, say, MapQuest but
consumes a fraction of the bandwidth, because using the web in a more
architecturally consistent way, it can take advantage of the browser (or
local proxy) caches.
If you were to deliver a mapping applications to, say, schools in
africa, which one would you use, MapQuest (where every click is a new
120Kb gif file) or GMaps (where there is virtually no traffic generated
at all after the initial load... which, for normally, can be consumed by
a local transparent proxy)?
Interesting you pick "schools in Africa", since I am involved with a
technology project in Africa. We have built a technology centre to serve
the local communities. Connection in our target area is Satellite (very
expensive per byte) and the equipment is run from a generator (very
expensive in terms of fuel, although I'm not sure Cocoon can help with
that).
In addition the hardware is old recycled stuff, 386's in most cases
(although this is a different issue and covered by other posts)
What is needed in such environments is as close to zero data transfer as
is possible. Caching is only useful for static content, even then it is
only useful if more than one person wants the same data (true for thick
clients this will be the case, but then a thick client is allot of data
to transfer - see above).
For dynamic content we need to be able to strip the feed to the absolute
minimum, that means processing on the server before it is sent to the
client. The earlier example of requesting a limited set of data using
SQL *is* server side processing and only serves to illustrate my point
(or so I believe).
Using your mapping example, we would want to say I want this map, with
only the X, Y and Z layers. Then have that processed on the server,
compressed and sent to the client.
Even something as simple as browsing the web in these environments
requires server side processing to strip out unneeded rubbish in the
original source (think of all those pages generated by Word for example)
120Kb sounds like nothing to most of us, but to a very large portion of
the world it is a very large amount. Even if Cocoon were obsolete for
most of us on this side of the digital divide, it would still be very
valuable in for those on the other side.
Ross