New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MediaWiki's service-oriented architecture (SOA) and what it means for SMW? #1170

Closed
mwjames opened this Issue Sep 24, 2015 · 4 comments

Comments

Projects
None yet
4 participants
@mwjames
Copy link
Contributor

mwjames commented Sep 24, 2015

[0] talks about service-oriented architecture (SOA) and the introductory text sounds as if installation of MW is becoming more difficult in future and would require mandatory external services to be installed in order to run a bare-bone MW.

The future of mediawiki is based on service-oriented architecture (SOA). That much has been decided 2 years ago and many efforts are going in that direction. Meanwhile, we are still supporting (or are supposed to be supporting) mediawiki running as a pure PHP/JS install without services.

@kghbln @JeroenDeDauw @ckoerner @hexmode Maybe a topic for the SMWCon on how this change (or requirement) would influence running Semantic MediaWiki (given its close dependency on MW) for users not running a server farm or a full IT environment.

[0] https://phabricator.wikimedia.org/T113210

@mwjames mwjames added the question label Sep 24, 2015

@ckoerner

This comment has been minimized.

Copy link
Contributor

ckoerner commented Sep 24, 2015

This is something I really want to discuss in my talk on where MediaWiki is going. I encourage everyone to provide feedback and share this topic with folks. It's an interesting time to be alive. 😄

@mwjames

This comment has been minimized.

Copy link
Contributor

mwjames commented Sep 24, 2015

General questions

Well, how would a service-oriented architecture (SOA) MW effect user in terms of:

  • ability for an easy installation environment (now you just download a tar file, run the installer, and your done)
  • ability to update existing installations and its extensions
  • the requirement to run node.js as a service

What would be the benefit/cost for users (not of the size of WMF) to run MW with external services such as node.js, cassandra, or parsoid.

Why would I (as a user) need a VE/Parsoid with the burden to maintain such service (and keep them updated/alive) just to a have a fancy wiki-editor with a more appealing visual appearance?

SMW specific

Given the lack of response on inquiries [0] to help extension developers to integrate SMW and VE, or answer questions on how wikitext parsing [1] suppose to be integrated with Parsoid I'm hesitant to see a fruitful outcome in terms of VE integrability.

[0] https://lists.wikimedia.org/pipermail/wikitech-l/2015-July/082441.html
[1] https://phabricator.wikimedia.org/T76278

@hexmode

This comment has been minimized.

Copy link
Contributor

hexmode commented Sep 26, 2015

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 update 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.

In order:

  • 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 @jamesmontalvo3 and @darenwelsh have been working on Meza1 to help set up a MW server.
  • During a meeting with the ED 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 above, combined with new forms of distribution should address the problems of Training, Effort and Complexity.

To your specific point about node.js: 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 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 WMF. 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.

@JeroenDeDauw

This comment has been minimized.

Copy link
Member

JeroenDeDauw commented Sep 27, 2015

Warning: not very constructive rant up ahead:

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.

Services neither solve the existing coupling problems, nor are they required to achieve proper isolation in new code. Decisions such as "we will move MediaWiki towards SOA" come over to me like saying "we will now use this big hammer for all our upcoming construction work".

MW architecture committee

Gets a vote of non-confidence from my side based on what I've seen so far.

@mwjames mwjames closed this Mar 12, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment