money out of this :)).
For what it's worth, this brings to mind a couple interesting examples of
this pattern:
*
On Tue, Jan 20, 2015 at 3:37 PM, Markus Glaser <glaser(a)hallowelt.biz> wrote:
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(a)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
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l