On Fri, 18 May 2001, Henry Minsky wrote:
> One thing I have wondered about is compression of text for iMode.
> At a max of 9600 baud, you would think you could get some significant
> gains by compressing text on the fly between server and keitai. Maybe
In the conventional web this is allready widely supported
(by the browsers) but mostly unknown (by the developers)
feature. Most browsers releases since 1999 are capable of
receiving compressed content. "Most" meaning all HTTP 1.1
compliant browsers.
See: 14.3 Accept-Encoding in,
http://www.w3.org/Protocols/rfc2616/rfc2616.txt
When requesting for the page the client sends an
Accept-Encoding: <accepted encoding methods> header.
If the client accepts gzip encoding the server first checks
if it allready has the corresponding page compressed on
it harddrive and sends it.
If not the server compresses the page on the fly and sends
that.
When the client receives the page it automatically
gunzips the page before rendering it. All this is transparent
to the end user (except that the pages usually load faster).
If the page was requested by non HTTP 1.1 compliant
browser the page is simply sent back uncompressed.
The speed gain is huge over slower networks. Even though
one might think othwerwise it actually reduces the stress
on the serverside too. Since the time used to serve the page
to the client is reduced (even the time spent sending
the page and the time spent compressing the page combined)
the httpd process is released earlier and is able to start
to process the next request, thus reducing the overall server
load.
All of this was standardized before WAP came out. Still they
had to reinvent the wheel and "compress" the data using WBXML
(or whatever it was called).
--
Mika Tuupola http://www.appelsiini.net/~tuupola/
[ Did you check the archives? http://www.appelsiini.net/keitai-l/ ]
Received on Fri May 18 11:50:34 2001