On Fri, Nov 6, 2015 at 11:13 AM, C. Scott Ananian cananian@wikimedia.org wrote:
Let's not let this discussion sidetrack into "shared hosting vs VMs (vs docker?)" --- there's another phabricator ticket and summit topic for that ( https://phabricator.wikimedia.org/T87774 and https://phabricator.wikimedia.org/T113210.
I only mentioned this portion of the discussion because I can't think of any other reason your initial proposal makes sense, since it's essentially discussing ways to distribute and run a set of microservices. Using docker requires root, which isn't available on shared hosting. I'm fine ignoring this topic in this discussion, though.
I'd prefer to have discussion in *this* particular task/thread concentrate on:
- Hey, we can have JavaScript and PHP in the same packaging system. What
cool things might that enable?
* Hey, we can have JavaScript and PHP running together in the same server.
Perhaps some persistence-related issues with PHP can be made easier?
- Hey, we can actually write *extensions for mediawiki-core* in JavaScript
(or CoffeeScript, or...) now. Or run PHP code inside Parsoid. How could we use that? (Could it grow developer communities?)
You're not talking about microservices here, so it's at least partially a different discussion. You're talking about adding multiple languages into a monolith and that's a path towards insanity. It's way easier to understand and maintain large numbers of microservices than a polygot monolith. REST with well defined APIs between services provides all of the same benefits while also letting people manage their service independently, even with the possibility of the service not being tied to MediaWiki or Wikimedia at all.
I'd posit that adding additional languages into the monolith will more likely have the result of shrinking the developer community because it requires knowledge of at least two languages to properly do development.
* How are parser extensions (like, say, WikiHiero, but there are lots of
them) going to be managed in the long term? There are three separate codebases to hook right now. An extension like <gallery> might eventually need to hook the image thumbnail service, too. Do we have a plan?
This seems like a perfect place for another microservice.
And the pro/anti-npm and pro/anti-docker and pro/anti-VM discussion can go into one of those other tasks. Thanks.
You're discussing packaging, distribution and running of services. So, I don't believe they belong in another task. You're saying that alternatives to your idea are only relevant when considered on their own, but these alternatives are basically industry standards for the problem set as this point and your proposal is something that only MediaWiki (and Wikimedia) will be doing or maintaining.
- Ryan