There has been some recent active discussion in the MediaWiki (MW) (see “The end of shared hosting” on phabricator) and SemanticMediaWiki (SMW) communities (see this discussion on github) about Service Oriented Architecture (SOA) and the future of MediaWiki.
Part of that discussion revolves around shared hosting which is where many people have deployed their wikis. I posted some of my thoughts on this for other people in the SMW community, but I don’t want to deprive anyone who loves to read my writing, so I’m copying it here.
I’m not sure I’m the best person to talk about the SOA approach that MW is taking. One thing is clear, though: A SOA approach does not work in shared hosting.
The best place to have this discussion is with Rob Lamphier and the MW architecture committee at the developer summit in January. I encourage anyone interested in this to find their way to San Francisco for that. That said, I do have some thoughts…
While the simpler, nostalgic past has meant that installing a wiki just required access to a single service (typically MySQL) the growing dependence on auxiliary services has made this “download and go” approach harder.
There are several objections to the SOA approach. Here are a few, but please be sure to add to the list:
- Cost — shared hosting is relatively cheap.
- Training — shared hosting means someone else is managing the server and you don’t need to have or maintain that skill.
- Effort — shared hosting allows you to focus on the site, not the running a server.
- Complexity — related to the previous two, shared hosting means you only need to be concerned with managing one aspect of your site.
These points are addressable, though:
- Cost should be a relative non-issue. Amazon’s EC2 can be had for free or as little as $10 month. Linode has similar service, a little friendlier UI and other hosters like M5 and Rackspace are providing even cheaper alternatives.
- I’ve been working on Ansible scripts to set up a server from scratch and James Montalvo and Daren Welsh have been working on Meza to help set up a MW server.
- During a meeting with the Wikimedia’s Executive Director and leaders of the engineering department that Markus Glaser and I had last year, it was clear they were looking for someone to take a leadership role in developing new forms of distribution for MediaWiki.
- Software like the Ansible or Meza, combined with new forms of distribution should address the problems of Training, Effort and Complexity.
SOA architecture was first pursued in core MediaWiki with Parsoid‘s node.js implementation. PHP 7 is removing the primary argument that Gabriel Wicke used for writing Parsoid on node.js — speed. Parsoid has a ton of tests and it would make sense to use those tests to rewrite Parsoid in PHP to make deployment easier.There was a really good presentation at Wikimania by Ed Sanders about adapting VisualEditor (VE) for other uses. He pointed to a couple of bits of example code. I haven’t had the chance to look at them yet, but these were apparently clear examples of how to use VE for things in MW besides editing the complete page.I have already been agitating for fewer services. The counter argument is that MW has grown into a monolithic piece of software and using services allows developers to isolate their work and control their interfaces better.That is a good thing, but there is no reason this sort of isolation and control couldn’t be accomplished using the same platform and easy deployment that PHP has offered to many users in the past.
So, what does this all mean for SMW?
I think it is obvious that the status quo isn’t going to work. For one thing, there is already poor communication between the MW and SMW developer communities. As the survey we recently completed clearly shows, many users of MW do not see SMW as a separate or even extra piece of software. I think it is a given that many end users of wiki sites see the functionality that SMW provides as just a normal part of their wiki.
That means we need to get developers who are familiar with SMW to interact with the developers at the Wikimedia Foundation. The developer’s summit would be a good place to start.
Working with the architecture committee — helping them understand the needs of users and developers outside of Wikimedia projects — would help them use their role as leaders of the MW developer community in ways that would help steer MW development so that projects like SMW could continue to depend on the MW platform.
Instead of pining for the past, we need to shape the future by making sure our voices are heard.