On Sun, 07 Apr 2013 04:10:23 -0700, Bartosz Dziewoński
<matma....@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.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
