On Sun, 07 Apr 2013 04:10:23 -0700, Bartosz Dziewoński matma.rex@gmail.com wrote:
Thoughts?
This sounds like a really ugly and hacky way to handle this issue. This is something that's mostly a WMF issue but this solution would involve all general updates being accompanied by a hack just for WMF. It also wouldn't scale well to extensions. I also have a felling that it would fall apart quickly if we make say 3 or more incompatible css changes within a month. We'd have pages with three different timestamps. And the conflicts would re-appear on some pages.
It sounds more like an issue with how smart ResourceLoader is and our current concept of what should and shouldn't be purged.
We already have other issues with how smart RL is. Or rather we have issues with the fact that on the client side RL is smart about handling dependencies and everything. But on the server side RL is completely stupid. All it does is serve precisely what it's asked to serve out. Then leaves absolutely everything else up to the client side scripting. There is absolutely no server side handling of dependencies. This leads skins that can't require JS to serve out their critical stylesheets having no concept of dependencies (which is killing my ability to fix my mistake with things like commonElement.css and turn them into modules and implement remoteSkinPath support), hacks like addModuleStyles which is buggy and bypasses parts of RL, and bugs like css being double loaded because it was added server side with addModuleStyles and then a script loaded a second copy.
One of the issues in general seems to be that we need to make ResourceLoader smarter. It needs to understand dependencies on the server side, give more information to the client about what it's already loaded to avoid double loading, and give it some level of understanding of versioning on the server side.
Right now our stylesheets loaded by the server contain no versioning timestamp (for cache breaking). Our HTML is cached for up to 30 days. And we try to clear css asap. From what I understand my guess is that we don't include the timestamp in the url because of how long the HTML is cached. In order to use the cache breaking timestamp the HTML of every page would have to be purged in order for the cache breaker to work. Since on old pages the cache wouldn't be broken and the client would use old css for some pages. So we use non-versioned CSS without long expires so we can purge that separately and have everyone use the css updates.
But from the issue we're having with incompatible css and html we might be wrong about that. Rather than trying to keep the css up to date all the time perhaps it's actually correct to serve old css on pages with old html instead of serving the up to date css. Even if it means that pages will be a little inconsistent with modifications to the UI. Some pages with old stuff and others with new.
For that we would start including timestamps for all css. And we'd make it so that the old css stays around at those urls so that on old pages the old css is loaded. To do that we could increase the time the server caches timestamped css. But more flexibly we might consider making RL smart about how it handles those timestamps. Do something smart with them instead of making them simple cache breakers/holders. Write a maintenance script; When you run it it creates a new snapshot containing the css of all the RL modules. The script could also be used to clear out old snapshots. RL would then be smart about serving things out of load.php. load.php would use the timestamp to serve out old css that was cached when you ran the script. That way if we make some incompatible css changes then we run the script before deployment. RL creates a snapshot. And after the deployment RL keeps serving the old snapshotted css for the old timestamps.