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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
