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