IMHO, the cases traditionally handled by "tiny one-off wiki on shared hosting" would be better served by migrating to a dedicated wiki hosting service which will actually update the software for security issues and new features.
I believe WMF should concentrate on the large-scale hosting case, with Vagrant and similar VM solutions for easy dev & one-off setups where people are willing to maintain them themselves.
This should include better support for creating and maintaining large farms of small independent wikis.
We should also either spin off an affordable for-pay no-ads wiki hosting company, or let people create one (or multiple) and direct people to them.
-- brion
On Thu, Jan 15, 2015 at 10:38 PM, Bryan Davis bd808@wikimedia.org wrote:
There has been a lot of talk over the last year or so of how and when to move MediaWiki to a service oriented architecture [0]. So much so that it is actually one of the a marquee topics at the upcoming Developer Summit.
I think the problem statement for the services RFC is dead on in describing issues that MediaWiki and the Wikimedia Foundation face today with the current monolithic MediaWiki implementation. We have organic entanglements between subsystems that make reasoning about the code base difficult. We have a growing need to API access to data and computations that have historically been only presented via generated HTML. We have cross-team and cross-project communication issues that lead to siloed implementations and duplication of effort.
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}}. 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.
One of the bigger questions I have about the potential shift to requiring services is the fate of shared hosting deployments of MediaWiki. What will happen to the numerous MediaWiki installs on shared hosting providers like 1and1, Dreamhost or GoDaddy when running MediaWiki requires multiple node.js/java/hack/python stand alone processes to function? Is the MediaWiki community making a conscious decision to abandon these customers? If so should we start looking for a suitable replacement that can be recommended and possibly develop tools to easy the migration away from MediaWiki to another monolithic wiki application? If not, how are we going to ensure that pure PHP alternate implementations get equal testing and feature development if they are not actively used on the Foundation's project wikis?
Bryan
Bryan Davis Wikimedia Foundation bd808@wikimedia.org [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l