> But there's plenty of room for other initiatives (some could even make money out of this :)).
For what it's worth, this brings to mind a couple interesting examples of this pattern: * https://travis-ci.com/ (and its free counterpart, https://travis-ci.org/), the hosted version of https://github.com/travis-ci/travis-ci * https://gitlab.com/, the hosted version of https://github.com/gitlabhq/gitlabhq On Tue, Jan 20, 2015 at 3:37 PM, Markus Glaser <[email protected]> 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: [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 > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
