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!" :)
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).
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)
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)