On Fri, Nov 6, 2015 at 11:13 AM, C. Scott Ananian <cananian(a)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