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: