Thanks for all of the great comments people, it helps.
On Tue, Nov 10, 1998 at 11:15:01PM -0600, Chuck Shepherd wrote:
> The only way to do this was to set core writeable.
Actually, I should clarify this, because I've received a lot of flack
about that setting :)
Basically, I did not add it because I expected people to run with a
non writable core, but because I wanted administrators to conciously
realize the results of their actions--so that later when they try an
upgrade and it will conflict with changes, then they are not
> One idea might be to have Core "packages".
I've considered this off and on for a long time (almost since day
one), and recently it's moved up a few notches on my importance list.
The primary issue with modules I have is I'm not sure how to define
them. That is, you have several different issues in how to specify
what falls within a single module, and these can vary in what modules
exist. For instance, is the primary criteria subsystem? Or perhaps
functionality? Or even simply features? Consider networking, if its
just subsystems, then the module is probably $network and its
children... but if its functionality, you should probably include
every object which uses the network API... but that is unrealistic...
features is probably the most realistic, but also the most work (as
you have more packages).
But the core reason they havn't been implemented yet is because most
systems are rather inter-dependant. If a change is made to the parser
it may break commands--so while you could just upgrade the parser
module, all commands would then be broken--would you have to go out
and grab all of the varied command modules as well? Then you'd also
have all of your custom commands too... Are the benefits of all the
work to create this worth the pay-off?