-----Original Message-----
From: wikitech-l-bounces(a)lists.wikimedia.org
[mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of
Platonides
Sent: 15 December 2008 23:41
To: wikitech-l(a)lists.wikimedia.org
Subject: Re: [Wikitech-l] Future of Javascript and mediaWiki
Jared Williams wrote:
Here's the paper (PDF)
http://sdch.googlegroups.com/web/Shared_Dictionary_Compression_over_HT
TP.pdf
?gda=Cn21OV0AAADesD7oVzP2tIH3YMhCCYbwV7wKw6Y_LNfrKuXmihkMeg12alwZyuoqs
E-BiY8
8xfLrk0HuZRJs1gcUl6mErWX6yPI8Lq4cE5IelfQO528z8OU2_747KStNgkfeVUa7Znk
The idea being you could get a sdch capable user agent to
download the
concated & gzipped javascript in a single
request (called a
dictionary), which quick testing is about 15kb for
en.mediawiki.org,
cache that on the client for a long period.
Then the individual requests for javascript can just return
a diff (in
RFC
3284) between the server version and the client version has in its
dictionary.
Obviously if the diffs get too large, can instruct the user
agent to
download a more up to date dictionary. Something
around 30 bytes of
body (off the top of my head) is the minimum size if the server &
client versions are identical.
CSS also could be managed similarly.
Also possible to put the static (inline html) in templates into the
dictionary, together with a lot of the translated messages,
to try and
reduce the HTML size, though not sure how
effective it'd be.
Jared
I don't see how it will help. The client still needs to
download it. Be it the dictionary or the JS.
What could be benefitted from SDCH are is skin. Instead of
transmitting the skin, diff borders, etc. all of that would
be in the dictionary, decreasing the transfer per page.
Gzip will compress concatenated javascript files a lot better than the
gzipping the individual files.
Here's what FF is receiving from Main_Page atm...
Size URL
46634
n=raw&ctype=text/javascript&smaxage=21600&maxage=86400
Gzipping them concatenated results in single 15kb file.
Only needs to download it once, and kept on client for months, as server can
send a diff to update to the most recent version at any time, rather than
having to send a whole new js file.
SDCHing MediaWiki HTML would take some effort, as the page output is between
skin classes and OutputPage etc.
Also would want the translation text from \languages\messages\Messages*.php
in there too I think. Handling the $1 style placeholders is easy, its just
determining what message goes through which wfMsg*() function, and if the
WikiText translations can be preconverted to html.
But most of the HTML comes from article wikitext, so I wonder wether it'd
beat gzip by anything significant.
Jared