On 09/26/2012 01:54 PM, Krinkle wrote:
We're going towards a flexible modular system, which means components have dependencies and build on each other - as opposed to just "being there".
This sounds great, but I do see an important missing piece of infrastructure.
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 build on.
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?
Mark.
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 system, which means components have dependencies and build on each other - as opposed to just "being there".
This sounds great, but I do see an important missing piece of infrastructure.
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 build on.
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?
Mark.
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On 28 September 2012 02:47, Mark A. Hershberger mah@everybody.org wrote:
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.
After the ones about sending email and Common Lisp, we can add:
"Every app also expands until it contains a sketchy rewrite of apt-get."
c.f. Perl, PHP, Ruby, Python, WordPress ...
One thing to possibly think about: compatibility of any new system with Linux distro packaging mechanisms, like apt-get and yum. The less distro maintainers have to mess with MediaWiki the better.
- d.
mediawiki-l@lists.wikimedia.org