Proposal talk:Separate content from style
question: does the API at http://www.mediawiki.org/wiki/API:Changing_wiki_content already fulfil the requirements of this proposal, or is there more required?
Effectively, this proposal is a meta-proposal, recommending that wikipedia split the existing behemothic glob of (tedious) php code along strategic and clearly-defined MVC lines. (strictly speaking, it's only recommending a split along MC and V lines) Lkcl 11:27, 10 October 2009 (UTC)
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 01:12, 4 September 2009 (UTC)
- The major impact is the possibility to use wikipedia data outside wikipedia easily. --Wiso 14:06, 22 September 2009 (UTC)
One of the ways to do this separation would be to use XSTL transform. The input of this transform is an XML document that can be generated instead of the current HTML that goes directly to the browser. It is much simpler by the structure than exiting HTML content. Another document (XSLT transform) that is more tricky to write defines how XML is converted to HTML. However it is always the same. These two documents can be merged on a browser side , producing the input. Multiple XSLT transforms can be easily prepared, allowing to have alternative layouts. Audriusa 17:36, 6 September 2009 (UTC)
- i hate to say this, but using XSLT is like putting your head into the lion's mouth. the nice thing about having an API by which it is possible to get at the "raw" format however is that developers are free to do exactly what they choose to do - including putting the raw wikimedia through XSLT (first having been converted to XML) and other transforms. so, yes, great idea as LONG AS the "raw" format of the wikimedia data stays the hell away from XML. Lkcl 21:31, 1 October 2009 (UTC)
Proposal:Distributed_Wikipedia contains a front-end API outline
i started out with two APIs in Proposal:Distributed_Wikipedia but am slowly coming round to the idea of splitting it into two proposals. the first a distributed p2p backend proposal and the second an API inspired by facebook (and opensocial). each and every function that is possible to be performed using the HTTP wikipedia.org front-end should ALSO have a DIRECT analogue in the API, such that it would be entirely possible to just "lift" the code in the wikipedia source code, breaking it right down the middle and putting in the API in between the two halves, and the resultant front-end, running still as a web service, would look absolutely no different to the users. if you can achieve that, then it is possible for _anyone_ to write their own full-blown replacement wikipedia front-end GUI, using the published API.
that's the level of committment that you need. _everything_ has to be covered by the API. login. create user. read page. edit page. see change history. undo. view discussion. edit discussion. upload images and other attachments. search pages. absolutely everything, down to the last and most obscure bit of the current wikipedia.org's HTTP interface. Lkcl 21:31, 1 October 2009 (UTC)