https://bugzilla.wikimedia.org/show_bug.cgi?id=14404
--- Comment #30 from Philippe Verdy <[email protected]> 2010-07-19 20:02:51 UTC --- > While some projects may indeed want uncacheable or 1-second lifetime (there's > hardly a difference between these two) pages, I'm pretty sure the servers > wouldn't like that very much. At Wikimedia, we err on the side of caching over > correctness in quite a few situations. You're right. But it's a matter of project-specific policy about their local use of caches for prerendered pages. The policy will just have the effect of increasing the computing the final lifetime to a sustainable level for most frequent pages, when some limited subsets of pages (most probably within specific namespaces with stronger modification policies) will require to be able to track smaller precisions. Note that heavily used and modified discussion pages could have a high precision as long as they are modifiable, but later they will be archived, or they may be edited in separate subpages, for example one for each day, so that a container page will still avoid transcluding older pages or archived pages that will have a long lifetime (because they will no longer depend on the use of magic keywords like {{CURRENTSECOND}} or {{PAGESINCAT:1}}): Those page archives, even if they remain modifiable would be moved to a namespace where they have a longer cachability, or where they will be frozen (by blocking administratively all later modifications), so that they won't be impacted by their smaller lifetime in caches. Special statistics pages on the server, for example, can perfectly have a very short lifetime as their layout is easily fixed and these pages are not directly modifiable (so there would be no risk that an included template would have to cause the page to be rendered again each time the template is modified. Their HTML or wiki code will be built from stable PHP server scripts (which can't be modified without administrative access to the server, using special admin tools that will specifically flush their cached rendering, if it is stored). If ever these special pages (with low lifetime and constantly updated dynamically) are transcluded within user-modifiable pages, the policy applicable to these user pages will still reincrease the lifetime to the minimum acceptable litefime. So there will be no problem at all, even if those user pages do not reflect the most instantaneous state of these special pages. But when the renderer will rebuild the wiki source of these user pages, it will get access to the instant state of these pages, and will cache it for a longer time than what you would get by visiting directly these special pages. In fact, these short-time special pages could even be denied direct access to normal unpriviledged users, even if these pages may be transcluded, or the server may choose to expose to these users only their cached version. The same can be applied to stable (patrolled) versions of pages which could benefit a lot of longer lifetimes in the cache, as they live within a stable and unmodifiable update id which does not need to reflect any current state of the server. Some wiki projects only work with stable versionned pages, and edits are only visible by selected patrolling users (that can validate a version), or only by users that performed these updates (so these newer updates don't even have to be cached). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
