Proposal talk:RPC-based facebook-esque API
lkcl's personal preferences on implementation details
- for the front-end i'd recommend and prefer a JSONRPC interface, simply because i've seen how incredibly easy it is to write JSONRPC services. plus, from a "marketing" perspective of this proposal, it's pretty easy to tell people "duUuR! go look at developer.facebook.com or go look up opensocial! duUuH!" :)
- for the reference front-end desktop and web app i'd recommend that the stand-alone front-end be done using http://pyjs.org simply because i've again, seen not only how easy it is to write pyjamas apps but also because the same python application could be compiled to javascript _or_ run as a desktop app under Trident (the MSHTML engine behind IE), under XULRunner (using hulahop) or under Webkit (using pywebkitgtk).
Frameworks such as GWT and Pyjamas "take care of" all the usual browser incompatibilities that are normally associated with RIA javascript-only "Web 2" interface design. If i didn't detest java to a degree that is easily justifiable yet near-pathological, i _would_ recommend GWT... but the GWT team have explicitly stated that they point-blank refuse to port GWT to run as a desktop-deployable application. they state that "it is perfectly possible to deploy Adobe AIR or other javascript stand-alone browser engine" as if that will somehow help. Pyjamas on the other hand has the Pyjamas Desktop version, where the _actual_ python is executed *direct*, under the standard http://python.org interpreter, which has the added advantage that you have full access to the standard python libraries (which you can't get, not without difficulty i.e. a plugin, in a web browser restricted environment).
Google Gears / HTML5
a potential mini-implementation, especially if the API is an HTTP-based RPC mechanism, could involve offline storage of wikipedia pages inside web browsers HTML5 SQL storage and/or google gears. GWT has support for gears; pyjamas has ported the gears SQL support but not the offline storage (yet).
Impact?
Some proposals will have massive impact on end-users, including non-editors. Some will have minimal impact. What will be the impact of this proposal on our end-users? -- Philippe 00:08, 3 September 2009 (UTC)
XMPP / (+wave)
This is a perennial proposal.
Some things have changed in the mean time, however.
We could actually just hook up with the (then) existing Wave architecture? --Kim Bruning 10:35, 3 September 2009 (UTC)
- will Wave actually exist (in time), in implementations outside of google [pseudo-proprietary] servers / services? i.e. will google FORCE people to utilise google servers, just like they have done with google "chat", by releasing the client but not the server implementations, and designing the client specifically around client-server protocols (which get called p2p) rather than FULLY peer-to-peer independant protocols which have absolutely zero dependence on centralised infrastructure? Lkcl 23:08, 30 September 2009 (UTC)
API
Does this offline idea include desktop MediaWiki editors via the API? Ecosystems such as Twitter have exploded because of participation through an API, and it's quickly becoming standard for Web companies and non-profits of many kinds. Steven Walling 01:32, 23 September 2009 (UTC)
- effectively, yes. Lkcl 15:48, 24 September 2009 (UTC)
This seems quite nice idea. Wikipedia is complex and valuable enough to have a dedicated frontend where it is possible to do many things differently than in a browser. The API would be language neutral, first trying slower, programming efficient languages like Ruby or Python, later somebody maybe will rewrite in C reusing code from some FOSS word processor or browser rendering engine. Also, some word processor teams may choose to develop Wikipedia plugins for media editing. AudriusA 20:48, 2 December 2009 (UTC)