On Jan 16, 2015 1:05 PM, "James Forrester" <jforres...@wikimedia.org> wrote: > > [Moving threads for on-topic-ness.] > > On 16 January 2015 at 07:01, Brian Wolff <bawo...@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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
