Jared Williams wrote: > Here's the paper (PDF) > > http://sdch.googlegroups.com/web/Shared_Dictionary_Compression_over_HTTP.pdf > ?gda=Cn21OV0AAADesD7oVzP2tIH3YMhCCYbwV7wKw6Y_LNfrKuXmihkMeg12alwZyuoqsE-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. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
