Hey, > > you're adding in a whole new set of incompatibilities.
> > How so?
> Extensions that use any of these extension libaries now depend on the
> version of MediaWiki and the version of the extension. That's a new set of
> dependencies that can be incompatible now.
It adds a component as dependency yes. It however does not add code as
dependency. One of the main reasons for creating well designed components
rather then throwing everything into one bucket is that it minimizes source
code dependencies. If you minimize dependencies (as a good programmer
should do on all levels), you also minimize the things that can cause
compatibility conflicts. It thus certainly benefits the user.
Imagine you have a package P, which contains components A, B and C. Only
package P is versioned and released. That it could be split into 3 packages
is a detail not visible to the end user. A is stand alone, B depends on A
and C depends on A. You want to install extension E0 that depends on P v1.0
or later. In particular, it depends on B, though again, the end user does
not know this. You want to make this install on a wiki where you already
have E1 installed. E1 depends on P v0.5 to v0.8. Internally it only cares
about C. This situation means you can in fact not install E0 and E1 at the
same time. The only reason for this is because to many things are packaged
together. If B and C where in their own packages, there would be no issue.
So one can for instance go from depending on package ABC that contains sub
components A, B and C to depending on A and B. That's two packages instead
of one if you look at it naively, though two components instead of 3 on
closer investigation. It is quite bad to force users to care about C while
there is no reason for doing so. They'll be affected by any issues that
occur in C for no good reason. Every time ABC has a new release because
something in C had to change, users will have to deal with this release,
since to them it is not visible this is pointless.
These are simple examples, with one component that could be split into 3.
The problems for the user get significantly worse if one throws more things
together and as this problem is replicated in the dependency chain.
Maintaining MediaWiki installs is already relatively difficult, due to a > lack of extension management. Many extensions are also poorly maintained,
> and just getting an extension that works with your version of MediaWiki
> reliably is hard. Upgrades are incredibly hard due to this. Adding in
> another set of incompatibilities is going to make this much harder.
Like noted above, it is simply not the case more things become dependent on
each other. Rather the opposite.
Another example. Take the Diff library. It does not depend on anything
(except of course PHP itself). You talk about putting it into core. Imagine
Diff 0.7 with MW 1.23 and Diff 1.0 gets bundled with MW 1.24. Now I have
extension E0 that needs MW 1.24 or later. I also have extension E1 that
needs Diff < 1.0. Again the user runs into problems. In case Diff is merely
bundled with core, the user can resolve this by changing either Diff or MW
version. In case they are solidly glued together, installation is again not
possible for no good reason. Like the one before, this really is a toy
example, that merely illustrates how problems arise. The problems users
encounter in the real world are more significant.
Now you might ask, where are those problems you talk about? > just getting an extension that works with your version of MediaWiki
reliably is hard.
And finding a set of extensions that work together with that version is
even harder. And you'll have hassle whenever you upgrade. I've seen this
many many times, and have of course encountered it myself more then enough.
After years of listening to users reporting problems and clients running
into this, I have concluded that a lot of this could be avoided if people
did not introduce silly dependencies.
The Diff extension is a good example how how to get it right. Initially it
did not. It dependent on MediaWiki. It was throwing MWExeptions at places,
its tests derives from MediaWikiTestCase and whatnot. This bound it to MW,
putting in a requirement people have to deal with. This dependency has now
been removed, as there really was no reason for it, thus making usage of
Diff easier. Once again, this is the simplest example I could think of.
Sorry, I phrased that poorly. Here's my concern: If extension libraries are > generic enough that they could be considered core (Diff is a great
> example), then other extensions will likely use it like core functionality.
> Wikibase already is.
I already outlined how this can be problematic, depending on what you mean.
If you are suggesting to merge it into core somehow, and just having one
release for the whole thing, then it will cause hassle. Bundling would be
better. We are already doing this with some extensions. That is something
to look at on a per extension or per library basis though. Clearly we do
not want to bundle every library needed for any extension with core.
In fact, we can't do this if you consider usage of third party libraries.
Imagine you have this app A that uses some common library such as Monolog,
and you have two delivery mechanism plugins for this app A. First you have
B that is an interface to MW, second you have C that is an interface to
some other system. An attempt to "assimilate" A into core is going very
likely to end badly. The MW community is not doing a fantastic job when it
comes to interoperability and sharing of components with the rest of the
PHP world as it is. To me this is a quite unfortunate miss of opportunities. > These extensions won't get the same level of review as
> they would if they were core functionality.
This implies you are thinking of more then just bundling. Or not?
This is again something that will need judgement on case-by-case basis. In
case for Diff, the code quality requirements are significantly higher then
those of core, and these are not going to be lowered.
Is there any compelling reason that they are extensions, rather than being > added to core?
Hell yeah! See above :)
Jeroen De Dauw http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
Wikitech-l mailing list