[MUD-Dev] Re: Why modules? (Was: Inheritable modules)

[Chris Gray <cg#ami-cg,GraySage.Edmonton.AB.CA>]

[Ola Fosheim:]

 >Can someone please explain WHY dynamic loading is desired?  I haven't seen
 >one good argument yet for why it should be dynamic.  People won't replace
 >their magic module twice a day. Probably not once a month either, a reboot
 >once a month is quite good!

Thinking about this, I find that I don't have any really good answer.

 >Here are some good reasons for making it static:

Plus, 6. Much easier to debug, in many environments

 >1. there is no object model

Perhaps because that is a contentious issue, so people have been tip-toeing
around it somewhat.

 >2. interfacing is generic

There is some motion away from that, but the ability to add in modules
that are completely unanticipated is a good thing to not throw away.

 >3. modules are reusable

I view that as a good thing.

 >A MUD is not exactly an OS, an OS caters for many _ independent _
 >applications, running on a wide variety of hardware with different
 >functionality.  Implementing the OS metaphor is a mistake in my opinion. 
 >Can somebody please explain what MUD related advantages these modules have
 >over regular libraries?

I agree with what you are saying here. I've been pretty-much glossing
over suggestions that the core be modelled on an OS.

What I like about the whole modular approach is the fact that I can
then stop concerning myself with all aspects of the MUD server. I've
got a server, and have done all of those things, but there are a number
of them (e.g. the database code) that I would much rather forget about,
and leave to someone who is interested in that sort of thing.

If talking about a system that is fully modular and has dynamically
loaded pieces has enough "cool" factor to make people excited enough
about it to actually do something, then that alone is reason enough
for me!

--
Don't design inefficiency in - it'll happen in the implementation. - me

Chris Gray     cg#ami-cg,GraySage.Edmonton.AB.CA