https://bugzilla.wikimedia.org/show_bug.cgi?id=19190
--- Comment #5 from Michael Dale <[email protected]> 2009-06-15 22:24:09 UTC --- 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) Certainly central libraries like jquery and our core helper library could be grabbed once and cached indefinitely per urid (scriptloader presently requests core libraries separably) I know that kind of sucks to send out a new javascript packaging every time a user language interface update occurs. On the other hand it also kind of sucks to go out to the server on a separate round trip to get messages. Assuming that the average interface module code and its messages is well under 30k (minified and gziped) .. depending on your connection speed ... the time it takes to do an extra round trip to the server can more than kill the benefit of not re-downloading packaged gzip compressed JS ... so its a trade off... 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. (does the api support gziped output?) 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'). 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? 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. But for the mean time I think the script-loader offers advantages over the current setup. 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. 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. -- 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
