On Jan 16, 2015 1:05 PM, "James Forrester" <jforrester(a)wikimedia.org>
wrote:
[Moving threads for on-topic-ness.]
On 16 January 2015 at 07:01, Brian Wolff <bawolff(a)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.
- HTML storage only. Remove MWParser from the codebase. All
extensions that hook into wikitext (so, almost all of them?) will
need to
be re-written.
- Real-time collaborative editing.
- Huge semantic change to the concept of a 'revision'; we'd probably
need to re-structure the table from scratch. Breaking change for
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's
useful/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