I'm reminded of an old BBS system I once operated, then beta tested for, then alpha
tested and did a bit of development on.
It worked on old C=64 systems, hence was heavily memory use intolerant.
We used mini-modules that were swapped in and out of memory, with the main central
routines part of the primary system. One would call upon the primary routines that
remained memory-resident, while the rest would swap in and out as needed.
Yes, I know about current library use, this is memory resident in the core of the system.
THAT is where we are again today, where one does NOT want monolithic monstrosities
clogging up the http server, nor do we want tangle code beginning to sprout up.
So, the centralized dependency database IS valuable. WITH standards imposed for inclusion,
so that we don't end up with the mess that some packages end up in some Linux
distributions, lacking clear dependancies.
One side issue is security, which I'm certain, we'd all agree upon. Where security
patches for the code are also monitored and centrally managed as a required part of the
dependencies. Lest some Wikis end up compromised by malicious code, to share the misery.
Hence, loosely coupled isn't quite the answer, lest either tangle code prevail or
insecure code prevail.
On Sep 27, 2012, at 9:47 PM, Mark A. Hershberger wrote:
On 09/26/2012 01:54 PM, Krinkle wrote:
We're going towards a flexible modular
means components have dependencies and build on each other - as opposed to just
This sounds great, but I do see an important missing piece of
First, I am absolutely in favor of a loosely-coupled, modular system
instead of just building a larger and larger core.
The problem, though, is that there is no way to install, use, or update
extensions apart from doing it by hand. Requiring the installation of
multiple modules by hand isn't going to lead to a thriving, modular
ecosystem. We need a dependency manager.
Thankfully, I think there is already a dependency manager that we can
I'm talking about Composer (http://getcomposer.org/
Of course, MediaWiki isn't aware of this dependency manager and so
MediaWiki's extensions aren't either. I've only looked at it briefly,
but it appears that adding support wouldn't be difficult at all -- it
would just mean adding a file to the git repository.
What do you think?
MediaWiki-l mailing list