Hello everyone,
On 19/01/15 06:47, Tim Starling wrote:
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.
I kind of agree. Instead of seeing things in black and white, aka shared hosting or
not, we should take a look at the needs of users who run their MW on a shared hosting.
What exactly do they consider "core functionality"? I don't think we
actually know the answer yet. To me, it seems very likely that MWs on shared hosts are a
starting base into the MW world. Probably, their admins are mostly not technologically
experienced. In the near future, most of them will want to see VE on their instances for
improved user experience. But do they really care about wikicode? Or do they care about
some functionality that solves their problems. I could imagine, templating is one of the
main reasons to ask for wikicode. Can we, then, support templating in pure HTML versions
of parsoid? Are there other demands and solutions? What I mean is: there are many shades
of [any color you like], in order to make users outside the WMF happy.
I see shared hosts somewhere in a middle position in terms of skills needed to run and in
terms of dedication to the site. On the "lower" ground, there are test instances
run on local computers. These can be supported, for example, with vagrant setups, in order
to make it very easy to get started. On the "upper" level, there are instances
that run on servers with root access, vms, in clouds, etc. They can be supported, for
instance, with modular setup instructions, packages, predefined machines, puppet and other
install scripts in order to get a proper setup. So shared hosting is a special case, then,
but it seems to have a significant base of users and supporters.
While the current SOA approach makes things more complex in terms of technologies one
needs to support in order to run a setup that matches one of the top 5 websites, it also
makes things easier in terms of modularity, if we do it right. So, for example, we (tm)
could provide a lightweight PHP implementation of parsoid. Or someone (tm) runs a parsoid
service somewhere in the net.
The question is, then, who should be "someone". Naturally, WMF seems to be
predestined to lay the ground, e.g. by publishing setup instructions, interfaces, puppet
rules, etc. But there's plenty of room for other initiatives (some could even make
money out of this :)). An ecosystem around MediaWiki can help do the trick. But here's
the crucial bit: We will only get a healthy ecosystem around MediaWiki, if things are
reliable in a way. If the developer community and the WMF commits to support such an
environment. In the current situation, there's so much insecurity I doubt anyone will
seriously consider putting a lot of effort in, say, a PHP parsoid port (I'd be happy
if someone proves me wrong).
So, to make a long story short: Let's look forward and try to find solutions.
MediaWiki is an amazing piece of software and we should never stop to salutate and support
the hundreds of thousands of people that are using it as a basis of furthering the cause
of free knowledge.
Best,
Markus
-----Ursprüngliche Nachricht-----
Von: wikitech-l-bounces(a)lists.wikimedia.org
[mailto:wikitech-l-bounces@lists.wikimedia.org] Im Auftrag von Tim Starling
Gesendet: Montag, 19. Januar 2015 06:47
An: wikitech-l(a)lists.wikimedia.org
Betreff: Re: [Wikitech-l] The future of shared hosting
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
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l