So I was thinking instead of just packaging in jQuery I should package in / move the entire mv_embed folder into the skins directory .. it does not make sense to maintain two branches reinventing what mv_embed.js provides in the process of refactoring other core mediaWiki javascript.

We will have to do something like that eventually anyway if we want to start including things like the add_media_wizard, firefoog & ajax copyByUrl status upload helpers, the Kaltura Sequencer etc. If you peek at the add_media_wizard code (which provides the firefogg upload helper) you can see its using mv_embed to manage its entry point into the interface libraries. This will also pave the way for video page includes to be <video> tags that get rewriten by mv_embed supporting firefox 3.5 javascript disabled users while retaining fall-backs and a html interface player for people with javascript turned on.

Mv_embed originally was a library for embedding video but now has morphed into a library for "embedding javascript interfaces". In essence this lays the groundwork for a more mash-able future since mediaWIki interfaces will be "embeddable" into other contexts just like the remote embedding of the video playback interface works. (ie opencongress embed metavid videos with their own skin / interface: http://www.opencongress.org/person/videos/400237_barbara_lee )

The vast majority of "video specific" code has already been factored out of mv_embed into libEmbedVideo libraries and the rest should be forthcoming. (reducing core mv_embed size to something pretty minimal) The scriptLoader approach has enabled the js code to become pretty modular so it should never result in including lots of js that you don't need.

== An overview of what core functionality mv_embed supports / stuff we don't want to maintain in two places:

* the javascript version of wfGetMsg called gM (in mv_embed) .. this function is simple right now but will get a bit more complicated as we add more advanced language msg support. * the mvJsLoader.doLoad helper function that is integrated with script loader so you can run doLoad('className', function(){ //stuff to run now that className is available } ... useful for dynamic script includes & it works well with front-loading libraries you know you will need. For example if your on a page with a video we can send the necessary libraries for video interface in the master packaged scriptLoader request and when the doLoad function is called it will skip the remote request to get those libs and jump to code it knows it can execute. But if you hit a video from a different path in the interface where we don't know if you would need the video lib (ie add_media_wizard could be used just for grabbing an image instead of a video clip) ... then you load the library on demand. * some mediaWiki convenience functions not available in jQuery core like: do_api_req that lets you contextually get mediaWiki api data given your context. (ie a add_media_wizard embed in a remote mediaWiki instance can transparently hit the commons api via json callback while if your on commons hit the api via ajax request.) * other convenient function like js_log, js_error, parseURI etc. * some patches to jQuery plugins that have not made their way upstream.

== Down sides ==

* Ideally we want to keep mv_embed "stand alone" support this involves a minor bit of trickery in the script server to detect if its in mediaWIki context or a stand alone package. If stand alone mode we provide logical entry points for other CMS's or static usage to make use of the code embedding helper code. Static includes of mv_embed.js (without the script server & localization) should continue to work fine. * this will bring a fairly large set of javascript into the distribution branch not all of which is "stable" but un-stable parts won't be accessible via the interface. (all the js is already on the live site under the extensions directory just not evoked)

== Way forward == Since mv_embed is already pretty smart about paths and context this is a really simple change technically involving renaming a path or two.

Other issues to consider is the other php entry points in the mv_embed folder like sample usage pages and cortado_iframe.php we can probably disable them for wikimedias usage.

peace, --michael