User:BPirkle (WMF)/Stuff/MediaWiki Framework Thoughts

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

The following arose from a Platform Team offsite meeting in July, 2021. I was unable to attend the meeting, but watched the recording and captured my thoughts here.

Definitions[edit]

The words "framework" and "platform" where used in the meeting, with some apparent confusion. Here are my thoughts on what each of those words mean in the context of MediaWiki. Disclaimer: much of this was plagiarized from a Slack discussion with DKinzler_(WMF).

Platform: a collection of enabling technologies. This often includes runtime environment, services, libraries, and protocols.

Framework: a structure for building a certain type of thing. This often has a "fill in the blank" feeling to it.

Typically, you call a platform's code, while a framework calls your code. Also, frameworks are generally opinionated and are good for building one type of thing, while platforms are generally more generic and useful for creating a wider range of things.

Of course, there's a lot of overlap and the lines are not always clear.

Communications Styles[edit]

I hereby propose a corollary to Conway's law : "if different parts of an organization have different communication styles, they will have great difficultly talking to each other about software structure". Much of the meeting seemed complicated by the different participants not having a shared understanding of the words being used. That doesn't mean that anyone's understanding was incorrect, it just means that the same word can mean different things to different people, which can complicate discussion.

Software Architecture[edit]

Software architecture is multifaceted. There are a number of different aspects, some of which may influence each other but which can also to some extent be considered independently.

Concepts like MVC speak to a different aspect of software architecture and organization than concepts like frameworks or the ability to have extensions. MVC is more about design patterns and code structure, frameworks are more about the ability to build something on an existing structure, and extensions are more about customizing a working piece of software.

For example, we could have an MVC architecture with or without the ability to use MediaWiki as a framework and with or without the ability to have extensions.

I'm not suggesting we even have a discussion about whether or not to have extensions - the decision to have them was made long ago and, as long as MediaWiki exists in anything resembling its current form, we'll have them. (And for the record, I agree with that.)

The point is, mixing discussions about too many aspects within one conversation can get confusing and overwhelming if we don't clearly distinguish which aspect we're talking about. Also, there's a subtle difference in the Expedition Team work (which at least thus far appears to be more about internal code structure of the existing MediaWiki software) and "breaking the monolith" (which may or may not be a good idea, and which we may or may not ever do, even if we decide it is a good idea).

MediaWiki Framework[edit]

This thought is specifically about the "framework" concept, what it could mean to us, and what some possibilities are.

I spent about a decade doing Drupal development in a previous life. For all its faults Drupal does a decent job with some of these distinctions. Or at least it did as of v7, the last version I used extensively. No idea what's happened since then.

Caveat One: Drupal uses the word "module" for what MediaWiki calls "extensions". I'll try to use the MW terminology below.

Caveat Two: Drupal isn't really as clean as I'm making it out to be. For example, the User extension creates the "users" table, and this table is directly referred to in Core. This turns the dependency model upside down and is IMO a Very Bad Thing.

Caveat Three: I'm not suggesting we change anything. This is more a collection of random thoughts than a proposal. I'm just looking for shared concepts/vocabulary to see where it does or doesn't lead.

Caveat Four: To be absolutely clear, I am NOT suggesting we rebuild MediaWiki on Drupal. Rebuilding MW on Drupal would be a terrible, disastrous idea which I do not support in any way. Drupal is great for a lot of things. This wouldn't be one of them. I'm just looking to see what Drupal ideas we might take some inspiration from.

With all that out of the way, Drupal 7 has:

  • Drupal Core. this is shared by all installations and is not replaceable. It is highly extensible, and is a "framework" by any sensible definition of the word. Drupal Core has concepts of pretty much every major thing that a Drupal site might want to do, but doesn't necessarily have concrete implementations of them.
  • Required Core Extensions. These are bundled with Drupal Core and are concrete implementations of some particular concept, like "User" or "Toolbar". These cannot be disabled, so they're "kind of" part of Core. But they're different in that they use the same extensibility mechanisms as every other extension. These typically implement essential functionality.
  • Optional Core Extensions. These are bundled with Drupal Core, but are different in that they can be disabled. These typically implement functionality that is very common, but which is not essential for Drupal to operate.
  • Contrib Extensions. These are freely available from drupal.org, but are not included with the Drupal Core download. You have to download them yourself if you want them. Many, probably most, are created and maintained by volunteers.
  • Custom Extensions. These are random things created by whomever and hosted (or not) wherever. I've created dozens if not hundreds of custom extensions that contained proprietary code and which were never published anywhere. These don't necessarily have to extend Core concepts - if a clever person uses the Core extension points to do something brand new and unforeseen on their own site, okay.

Regarding how we'd map similar concepts to MediaWiki, I'll use the authentication system as an example:

  • The actual "framework" part (let's call it MediaWiki Core) would have the concept of "authentication" and offer all necessary extension points for a concrete implementation.
  • Some bundled Core Extension would provide some sort of basic authentication, presumably username and password
  • Additional Contrib extensions, hosted at mediawiki.org, would implement things like SAML and OAuth
  • Anyone on the planet could create their own authentication extension and either publish it or not.

Either the bundled implementation would be Required, or else MW Core would be smart enough to realize that no authentication provider was enabled and fuss about it. So one way or another, there would always be an extension to provide a concrete implementation of the concept.

In the Drupal model, by the way, extensions can create their own extension points. I've written a number of Drupal extensions that did little on their own and existed only to be extended.