http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83754
Revision: 83754
Author: saper
Date: 2011-03-12 12:05:17 +0000 (Sat, 12 Mar 2011)
Log Message:
-----------
Update description how CentralNotice works to match the current landscape.
Modified Paths:
--------------
trunk/extensions/CentralNotice/README
Modified: trunk/extensions/CentralNotice/README
===================================================================
--- trunk/extensions/CentralNotice/README 2011-03-12 11:51:33 UTC (rev
83753)
+++ trunk/extensions/CentralNotice/README 2011-03-12 12:05:17 UTC (rev
83754)
@@ -1,52 +1,53 @@
-Proof of concept for the moment fiddling with an alternative sitenotice
-loading architecture. At the moment there's no backend logic or caching
-logic, I'm just testing the three-level loading.
+Wiki page HTML contains an unchanging bit that just sets JS variables
+about what site this is, then calls an external <script> to fetch site
+notice text. It also includes a facility to fetch a geolocation data.
-Wiki page HTML contains an unchanging bit that just sets JS variables about
-what site this is, then calls an external <script> to fetch site notice text.
+That second level is a stable URL which can be heavily cached within
+squids *and* cleanly purged on sitewide updates. This script is currently
+called Special:BannerController.
-That second level can be a stable URL which can be heavily cached within squids
-*and* cleanly purged on sitewide updates.
+BannerController fetches list of notices available by calling out to
+a third <script>, this time with the site info (project and language)
+and geolocation info in the query string. The third script, called
+Special:BannerListLoader provides list of currently available sitenotices
+for that match the given site and geolocation profile. It is possible
+that a number of notices will be available for the given site and user
+parameters.
-It itself is small, just calling out to a third <script>, this time with the
-site info (project and language) and a cache validation epoch / version marker
-in the query string.
+The fourth level is the bit that would provide the actual site notice
+text, and could be cached arbitrarily long in both squids and final user
+agents, since changed versions will get a new URL with a version number
+one level up.
-The third level is the bit that would provide the actual site notice text, and
-could be cached arbitrarily long in both squids and final user agents, since
-changed versions will get a new URL with a version number one level up.
-
The theory here is that it should interact better with big-site caching.
A user agent's first hit to the wiki will look something like:
* Load wiki page HTML
-* Load Special:NoticeLoader JS
-* Load Special:NoticeText JS
+* Load Special:BannerController JS
+* Load Special:BannerListLoader JS
+* Load Special:BannerLoader JS
-A hit to another page on the same wiki can skip the third hit:
+A hit to another page on the same wiki can skip step two and three, but
+may need to load notice in step four (if there is more than one available)
* Load new wiki page HTML
-* Load unchanged Special:NoticeLoader JS
-* skip cached Special:NoticeText JS
+* skip cached Special:BannerController JS
+* skip cached Special:BannerListLoader JS
+* Load Special:BannerLoader JS
-Then if the site notice changes, the system only has to purge that constant
-Special:NoticeLoader URL from squids, and right away at the next hit the user
-agent sees:
+Then if the site notice changes, the system only has to purge that
+constant Special:BannerListLoader URL from squids, and right away at
+the next hit the user agent sees:
* Load new wiki page HTML
-* Load new Special:NoticeLoader JS
-* Load new Special:NoticeText JS
+* skip cached Special:BannerController JS
+* Load new Special:BannerListLoader JS
+* Load new Special:BannerLoader JS
-We could spare hits on the notice loader by letting clients cache it for a
-shorter term as well, so a typical second hit looks nicely like:
+Caching Special:BannerListLoader for a while could delay visibility of
+changed site notices until the allowed age runs out, but if we manage
+*scheduled* site notices, we could send cache headers which will run
+out at the expected changeover time.
-* Load new wiki page HTML
-* skip cached Special:NoticeLoader JS
-* skip cached Special:NoticeText JS
-
-This could delay visibility of changed site notices until the allowed age
-runs out, but if we manage *scheduled* site notices, we could send cache
-headers which will run out at the expected changeover time.
-
-It might be nice to allow for quick corrections though, so caching for weeks
-at a time might not be wise. ;)
+It might be nice to allow for quick corrections though, so caching for
+weeks at a time might not be wise. ;)
_______________________________________________
MediaWiki-CVS mailing list
MediaWiki-CVS@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-cvs
