0.1 - Overview: Where are we going with this?

OVERVIEW

What is the 'core'? In theory, it's a THING which records and, via a simple function, reports the dbrefs of all the various packages installed on a MUSH. But, in practice, it's a little more than that. Once it builds some momentum,... once all of the 'feep' has had a chance to ripen, it has the potential to become a full-fledged MUSH maintenance utility. Therefore, in order to retain perspective on what actually constitutes the "core", great care must be taken in the development process to ensure that only "core items" get packaged with the core.

1. DEVELOPMENT

   This brings us to the development process. This core will be developed as a bunch of very small components, focused around the central 'registry object'. That is, in an effort to retain focus on what has been determined to be the 'core' (the 'one object linking all other objects'), all of the installation scripts for various additional features (maintenace tools, whatever) will be maintained and developed individually and separately.

   It is conceivable -- even highly likely -- that there will emerge some interdependencies between these separate packages. This is only natural (one package being a frill for another package, and so on and so forth). This further emphasizes the need to keep the 'core' isolated and protected from 'feep'.

   Yet, by maintaining packages individually in this way, there is also a great deal of freedom afforded to the user... freedom to decide which features and how many of them they want and/or need. And due to the 'script' quality of softcode installation, creating a larger package out of the smaller components becomes a relatively trivial task.

2. STANDARDIZATION

   There will, of course, need to be a few 'ground rules', in order to provide inter-operable standardization. These will be kept, as much as possible, to a bare minimum. And will further be divided into two groups:

   • "conventional procedures" recommended (but not mandated) for general community support (i.e., these are things that everyone, so far, basically does however they want... but which would simplify the world a lot if everyone did them consistently similar).
   • "mandatory procedures" for being considered 'WARPEDcore compliant' (very few of these, but at least two emerged from the first 2 lines of code I wrote for the 0.00alpha version), and to prevent conflicts with the above conventions.