On Jan 16, 2015 1:05 PM, "James Forrester" jforrester@wikimedia.org wrote:
[Moving threads for on-topic-ness.]
On 16 January 2015 at 07:01, Brian Wolff bawolff@gmail.com wrote:
Does anyone actually have anything they want that is difficult to do currently and requires a mass compat break?
Sure.
Three quick examples of things on the horizon (I'm not particularly
saying
we'd actually do these for Wikimedia's use, but if you're going to ask for straw man arguments… :-)):
- Get rid of wikitext on the server-side.
extensions that hook into wikitext (so, almost all of them?) will
- HTML storage only. Remove MWParser from the codebase. All
need to
be re-written.
- Real-time collaborative editing.
need to re-structure the table from scratch. Breaking change for
- Huge semantic change to the concept of a 'revision'; we'd probably
many tools in core and elsewhere.
- Replace local PHP hooks with proper services interfaces instead.
- Loads of opportunities for improvements here (anti-spam tools 'as a service', Wordpress style; pre-flighting saves; ), but again,
pretty much
everything will need re-writing; this would likely be "progressive", happening one at a time to areas where it'suseful/wanted/needed, but it's still a huge breaking change for many extensions.
Woo strawmen for me to shoot down! :)
Actually, The revision thing is fair. Its pretty engrained that a pages have linear revisions, and each one has a single author, allowing multiple authors or branching and remerging would probably be a big enough change to warrant calling it 2.0. And it kind of fits, since last time structure of revisions was really rearranged afaik was 1.5.
Without going into the merits/drawbacks of html storage - i dont see that being rewrite worthy. Whether the blob of data in the text table/es is html or wikitext doesnt really matter to mw. Especially with content handler.
Hooks are a very active area of code. The sort of area where i would guess that adding an extra 20ms of time per each hook invocation to call an external service would not be ok (since there are hundreds of hook calls in a request). I dont think the notion of a service fits with how hooks are used, at least for many hooks. Of course someone could make a heavier weight version of hooks for where its a good idea. Or even just a wrapper object that forwards things to a service. I dont think this is worthy of a 2.0.
--bawolff