Neil Kandalgaonkar wrote:
On 7/23/10 11:28 AM, Aryeh Gregor wrote:
On Thu, Jul 22, 2010 at 8:23 PM, Neil Kandalgaonkarneilk@wikimedia.org wrote:
I meant cached in the same way that skins are cached. Not cached in the sense of having a completely static page.
What do you mean when you talk about skins being cached?
What I mean is they aren't generated on the fly or anything. The related resources can be cached in Squid or on the client as simple URLs. Your proposal adds CSS rules dynamically, in JS.
Knowing the way mailing lists work, I don't think there's any point describing an idea that I now believe to be flawed, as I'll probably get a point by point rebuttal anyway.
I misunderstood some parts of your proposal, and I also was thinking that maybe CSS is a little more likely to work than JS.
Your answer is even more confusing. You can split the html pages in the wiki in two pieces: the content (the part that changes by editing the wiki source) and the chrome (anything else) that comes from the skin (sidebar, edit tabs, portlets...)
For users, the skin is not cached, it is generated on the fly. Whereas for anonymous users, it is cached as a static page in the squids (this is the reason wmf sites don't show p-personal for anons, so that all anonymous users share a single cache).
If the CSS classes are always in the page, you can change censoring level by loading a different stylesheets (eg. alternate stylesheets) Similarly, it could be handled by JavaScript and personal rules stored in localstorage.
It's probably just there, but I don't see where your "cached but dynamic" goes into the structure.