https://bugzilla.wikimedia.org/show_bug.cgi?id=19190
--- Comment #6 from Roan Kattouw <roan.katt...@gmail.com> 2009-06-15 22:40:21
UTC ---
(In reply to comment #5)
> To address Roan comments:
>
> What we are trying to avoid with the grouping is fewer round trips to the
> server. This is always a trade off with how much can be cached and how much
> extra stuff you want to grab at once (at a cost of having to grab that whole
> package again once any item of that package changes)
>
Yeah; fortunately, Wikipedia's i18n doesn't change very often (only at scap
time and when someone changes a MediaWiki: message that happens to be used in
JS).
> It would not be hard to retool the JS loader to grab the msgs in a separate
> api
> request if we want to try that.
I'll write a proof of concept-like thingy tomorrow.
> (does the api support gziped output?)
Yes.
> Also we
> would want to add the concept of urid's (unique request id) to the API (should
> be easy to add in 'if $wgRequest->urid is included send the cache forever
> header').
Presently, the API supports URIDs through the requestid parameter, and
URL-based caching through the maxage and smaxage parameters (which sadly don't
work on Wikipedia because of the Squids, will poke people about that).
> With the script-loader we check the latest version of any javascript
> file or mediaWiki page included and append a urid to the url. This way we can
> cache forever on the client and just update the URID when msg text, svn
> version
> or version of mediaWiki js pages change. Without this the client has to
> regularly issue a requests and check for a 304 response from the server
> (another round trip). Does the API support 304 responses?
>
No.
> Modern browsers will be doing request in parallel so grouping less beneficial.
> For maximum cache once could propose we don't group anything (that way we only
> download whats new). Unfortunately that makes it a lot harder to line up
> URID's
> (unique request ids) per resource. So you end up doing a bunch of 304 response
> checks.
>
> The ultimate setup would be a single resource that included an urid for every
> js / language req /css resource in the system that could be regularly 304
> response checked. That way any js file or any of its text messages get updated
> we have a new urid for it, otherwise we use the older urid and the client
> knows never to check the server to see if its updated since it had the
> cache-forever header sent out on it.
>
What about (ab)using $wgStyleVersion for this purpose, or introducing a similar
var?
> But for the mean time I think the script-loader offers advantages over the
> current setup.
>
It sure does, but it lacks parsemag functionality, which we're gonna need as
well.
> The problem with ~not~ storing the msgs in the JS is that it makes it harder
> to
> support stand alone operation. Although if we are going out to the server in a
> separate round trip anyway.. then not so big a deal. But the idea of putting
> the msg in the JS is it works without the script server and is easier to debug
> that way since you load the actual JS files with include the fallback English
> msgs used by the interface libraries your including in a given set of
> interface
> interactions.
>
One of the ideas I had was to write a .php script that generates message JS, so
you'd do <script src="foo.php?blah"></script> . Of course that PHP script would
set some pretty aggressive caching headers.
> Also the javascript interfaces are being designed to support 'stand-alone'
> operation this will make the easier to integrate into other CMS and
> environments and support remote embedding things like videos with a timed text
> interface with minimal round-trips to wikimedia servers.
>
>
> In the case PLURAL: we probably have to modify the way that is calculated on
> the server via having a array representation ie( array('1-4':X, '5':Y,
> '6-11':Z) (instead of having a php function with switch statements) then we
> can
> package that array into the JS and replace accordingly.... We should probably
> never mixed code with content translation representation .. This needs to be
> fixed for this case and other that will arise in the future.
>
About this: do we really *need* PLURAL in JS messages? Isn't there some way
that we can trade functionality for performance and just not support it?
--
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
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
