On 16/01/15 17:38, Bryan Davis wrote:
The solution to these issues proposed in the RFC is to create independent services (eg Parsoid, RESTBase) to implement features that were previously handled by the core MediaWiki application. Thus far Parsoid is only required if a wiki wants to use VisualEditor. There has been discussion however of it being required in some future version of MediaWiki where HTML is the canonical representation of articles {{citation needed}}.
Parsoid depends on the MediaWiki parser, it calls it via api.php. It's not a complete, standalone implementation of wikitext to HTML transformation.
HTML storage would be a pretty simple feature, and would allow third-party users to use VE without Parsoid. It's not so simple to use Parsoid without the MediaWiki parser, especially if you want to support all existing extensions.
So, as currently proposed, HTML storage is actually a way to reduce the dependency on services for non-WMF wikis, not to increase it.
Based on recent comments from Gabriel and Subbu, my understanding is that there are no plans to drop the MediaWiki parser at the moment.
This particular future may or may not be far off on the calendar, but there are other services that have been proposed (storage service, REST content API) that are likely to appear in production use at least for the Foundation projects within the next year.
There is a proposal to move revision storage to Cassandra, possibly with node.js middleware. I don't think that project requires dropping support for revision storage in MySQL. I think MediaWiki should be a client for multiple revision storage backends, like what we are already doing for file storage.
There's no reason to think Cassandra is the best storage system that will ever be conceived; the end of history. There will be new technologies in the future, and an abstract backend API for revision storage will help us to utilise them when they become available.
One of the bigger questions I have about the potential shift to requiring services is the fate of shared hosting deployments of MediaWiki.
As long as there are no actual reasons for dropping pure-PHP core functionality, the idea of WMF versus shared hosting is a false dichotomy.
Note that feature parity with Wikipedia has not been possible in pure PHP since 2003, when texvc was introduced. And now that we have Scribunto, you can't even copy an infobox template from Wikipedia to a pure-PHP hosted MediaWiki instance. The shared hosting environment has never been preferred, and I'm not particularly attached to it. Support for it is an accidental consequence of MediaWiki's simplicity and flexibility, and those qualities should be valued for their own reasons.
-- Tim Starling