https://bugzilla.wikimedia.org/show_bug.cgi?id=56509
Ori Livneh <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #11 from Ori Livneh <[email protected]> --- (In reply to comment #8) > Please read bug 41489 for more information why we ended up with the current > solution. > > Points to consider: > * In jquery.uls we cannot have dependencies on MediaWiki components. > * In jquery.uls (via jquery.i18n) we have a custom, json-based i18n file > format. > * Serving that file directly from bits is not possible because of > cross-origin > restrictions. > * We are not going to change the file format from json to anything > executable. > * We implemented API module which just servers the files as-is with some > caching. > * The API module does not have version based cache invalidation. > * Doing this via resource loader module would mean that we need to wrap or > reformat the json data into JavaScript on the fly and implement support for > that in jquery.i18n. This is what EventLogging does (schemas are JSON); see includes/ResourceLoaderSchemaModule.php in the EventLogging repository. JSON is already JavaScript, so to convert a JSON blob into something executable all you need to do is to wrap it in a function invocation. See the getScript module in that file. > > It's not obvious to me which action(s) should be taken here. Some options: > 1) Delay the api call until ULS trigger is clicked. This needs some > refactoring moving the trigger related tooltip message*s* from json to > i18n.php file. - Wrap the code in an RL module, a la EventLogging. - Defer loading until the page has finished loading OR the hover event on the cog is triggered. You don't have to wait for a user click, but you don't have to block the page either. > 2) Improve the caching of the api call Not an option, IMO. I don't have hard numbers, but if I recall correctly Yahoo! found that 30-40% of requests were always uncached, even with aggressive caching, presumably due to people resetting their browsers, using public kiosks, etc. A full HTTP request is really expensive. If you use ResourceLoader, you can fetch the JSON data and JS / CSS resources in a single request (which I think we'll want to do -- it's not just the messages that can be deferred but some of the JS/CSS too), and you'll benefit from localStorage when that gets rolled out. > 3) Use resource loader. I currently have no idea how this would look in > practice. Something like this: class JsonMessagesModule extends ResourceLoaderModule { function getDependencies() { return array( 'ext.uls.moduleWithInitFunc' ); } function getModifiedTime( ResourceLoaderContext $context ) { return filemtime('/path/to/json'); } function getScript( ResourceLoaderContext $context ) { $json = file_get_contents('/path/to/json'); return Xml::encodeJsCall( 'ext.uls.initFunc', array( $json ) ); } } > Hopefully we will have clarity on this on Monday. Have a great weekend. Yep! I think this is very solvable, so no sweat. Have a great weekend all. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
