Robb Shecter wrote:
Consider this true
scenario: I want to write a MediaWiki API client for editors;
something like the Wordpress Dashboard. Really give editors a modern
web experience. I'd want to do this as a Rails app: I could build it
quickly and find lots of collaborators via GitHub.
Not to "derail" the open-id idea I think we should support oAuth 100%
and it certainly would help with persistent applications and scalability...
But ...for the most part you can build these types of applications in
pure javascript. Anytime you need to run an api action that requires
you to be on the target domain you call a bit of code to iframe proxy
that action on the target domain and communicate its results to the
client domain with another iframe back to the client.
mwEmbed provides iFrame proxy as part of a uniform api request system
with the "mw.getJSON()" function. This that lets you just call that
function and mwEmbed works out if it needs to spawn a proxy or if it can
make the request directly.
Presently I hard-code the approved domains, but it would not be
difficult to add in process where users could approve domains /
applications. We could even do explicit approval for the set of
allowable api actions being requested. ( ie edit pages "OK" upload
"NO" )
This has been in use for a while and its how the uploading to commons
from the English encyclopedia page works with the add-media-wizard
gadget.
http://bit.ly/9P144i You can test it by simply by enabling that
gadget, then while editing click "insert image", then the "upload"
button, then upload to commons.
~Right now~ its a pure javascript gadget that is enabled on
(en.wikipedia) which calls another gadget on ( commons.wikimedia ) and
they setup two-way communication that way. To make things more
complicated all the javascript and html proxy pages are hosted on a 3rd
domain (
prototype.wikimedia.org ) and its not just simple api calls,
rather its full file uploading proxy with progress indicators and two
way error interactions.
In the context of the mwEmbed gadget this is more complicated than it
needs to be. I should package a apiProxy extension that could simplify
things like having an actual proxy entry point that does not load the
entire set of mediaWiki view page assets on every proxy interaction.
Also it could use some HTML5 type enhancements around cross domain
communication so the application could send and receive the msgs
directly where the domain is approved and the browser supports it.
Furthermore some versions of IE have to request user approval for the
iFrame to carry user credentials, but this can be avoided with a p3p
policy added to the response header.
http://bit.ly/13kpV
That being said it has worked oky for what I needed it for, and I think
it could be used for prototyping the "editors portal" as you have
described it.
peace,
--michael