ResourceLoader/Requirements/Neil Kandalgaonkar

NeilK starting this page off -- this is just my opinions, so far, mdale needs to add his / rewrite the structure.

Suggest good practice

 * clear separation between libraries for reuse by anyone, and scripts for use on a page.

Manage namespace
namespace and work within that. It should be easy to guess what PHP extension or gadget is managing what namespace and vice versa. e.g.  myExtension.php --> (mw.ext.myExtension). someGadget.js --> (mw.gad.someGadget)
 * control a particular namespace in JS, such as mw.*
 * have strong conventions and facilities for managing this namespace. Should be easy to carve out one's own part of the

Manage dependencies

 * scripts and packages should be able to declaratively state dependencies on JS packages, and optionally versions of these packages.
 * the system should translate these dependency declarations into URLs from which we load JS. This should be highly configurable as such URLs are often deployment-specific. (e.g. local server in dev, CDN in production).
 * multiple dependencies may be batch-requested, and the server will send a compressed and optimized package.
 * the server will extract and enable scripts in such a way that, before a script executes, its dependencies should be already loaded.
 * dependencies, and the dependencies of dependencies (etc.) should be loaded in the correct order.
 * it should also be possible to load libraries at runtime.
 * if script loading fails the user gets useful error messages about what went wrong.
 * By default, libraries already loaded in one session should not be reloaded. Nevertheless, one can force a reload or overwrite a namespace if you really want to.

Packaging - loading multiple libraries in one HTTP request

 * Requests for a set of libraries or scripts in a particular language can result in creating compressed package(s) on the fly. These packages should be cached for subsequent requests.
 * Nice to have -- precaching commonly requested packages, so there's no "first hit" penalty.

Development & testing

 * Should be able to turn compression + packaging on and off, with something simple like LocalSettings.php configuration and/or URL parameter
 * When debugging scripts in tools like Firebug, line numbers must match the line numbers of the script on the filesystem.

Localization
equivalent for gadgets (?), without any special action or configuration.
 * JS should obtain your preferred language exactly as every other part of MediaWiki does
 * Scripts should be supplied with strings that they need, in the preferred language, from the standard MediaWiki string database.
 * Declaration of 'needed' strings can be done piecemeal, but by default it should load the 'ExtensionName.i18n.php' file, or
 * JS should have access to the similar pluralization/gender/modifier facilities as PHP.

Strong jQuery integration

 * jQuery should be the standard for how JS interacts with the page
 * jQuery plugins should be the standard for how JS is reused
 * Easy to use and reuse a standard set of jquery plugins for MediaWiki
 * ability to add to this standard set on a per-project basis (Wikipedia, Wikimedia Commons, etc.)

??? Uncertain; should they be available at a standard URL and load into the standard JS namespace? Or should such components be in a URL related to their extension, and in their own JS namespace? e.g.  myExtension/js/foobar.js -> http://mysite/myExtension/js/jquery/jquery.foobar.js                                OR                             http://mysite/jquery/jquery.foobar.js
 * installing a PHP extension can install jquery components that are then available to other extensions and gadgets.

P.S. Things I'm uncertain about with JS2 / mwEmbed

 * 'standalone' capability; the JS doesn't have to be the same whether framework is there or not.
 * To me (NeilK) this seems like overreaching, particularly when it starts doing things like parsing Javascript to extract info it needs.


 * mwEmbed has random string and time functionality. Should move off to a library.