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: [email protected] [mailto:[email protected]] Im Auftrag von Tim Starling Gesendet: Montag, 19. Januar 2015 06:47 An: [email protected] 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
