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
        

Reply via email to