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