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

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

"Jon A. Lambert" wrote:

> I mentioned in an earlier post about not having a core but a set of
> modules that together implement core functionality....so in that
> vein...

Sounds a lot like a mud-oriented library which I suggested quite early on.

> Why couldn't each module implement it's own desired level of
> threading.  The loader would dynamically load the module and then
> start it running using a createthread(), startthread() mechanism.

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!

Here are some good reasons for making it static:

1. easier to implement
2. more portable
3. faster
4. more likely to be reusable in other (non-DevMUD) systems
5. allows for GLOBAL compiler optimization (on SGI for instance). This
   could be an advantage if you have a lot of traffic crossing object
   file boundaries.

Someone pointed out that function pointers are slow, that is not my
experience, but function pointers effectively turns off optimization
(inlining etc).

Maybe a 20% speed up isn't all that much, but have 4 levels of 20% speed ups
and you'll have a 100% speed up!

> Each module then starts as a single thread. The module writer need
> not even be concerned that they are threaded. Since there seems to be
> agreement that a common module interface is necessary, why not make
> that small bit of common inter-module interface code thread-safe by
> issuing the necessary locking mechanisms within the interface wrapper
> itself.
> 
> ModuleA calls ModuleB wrapper ----> ModuleB function
> ModuleB calls ModuleA wrapper ----> ModuleA function
> 
> All the code in the wrapper is fully reusable, generic and
> threadsafe.  It just contains bindings (data) for the module
> it is attached to.  Creation of wrappers could even be
> automated.  It might also be useful to require the loaded
> module to use a standard function name (i.e. init()) so
> we can have a handle to start a thread on.  And perhaps
> a kill() or stop() handle.

I think you are getting somewhere, except I don't believe that the
interfacing can be generic if modules are to be fully reusable.  The weird
thing about DevMUD so far is:

1. there is no object model
2. interfacing is generic
3. modules are reusable

This doesn't make sense. Something has to patch things up. If some entity is
to be reusable then somebody else HAVE to know more than the others.  I
don't believe that one can have an all-bottom no-top system?  (Unless you
want to go the Tierra way of life...) What the current approach seems to
imply is that there is some kind of master-module (director) that instructs
the other modules what to do, but why not make this master the glue in the
first place? And what do you have then?  A regular program using
libraries... *shrug*

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?

One should really try to separate analysis, design and implementation... 
You don't need a 1-to-1 correspondence between the conceptual design and the
implementation.  You can do OO in C as well as in assembly!

Besides, take a look at Irix, it provides a set of neat high-level
components for displaying graphs and such, but they always seem to miss 30%
of the functionality one would like them to have IMO.  Even STL is a plain
nuisance, roll-your-own seems to be easier (and a lot faster) 50% of the
time.  Doing it right with generic components seems to require some heavy
research or just plain evolution... Assume a domain (problem space) and come
up with an acceptable object model and you'll improve your chances of coming
up with a suitable modular approach with clean APIs...

I'm not questioning that there will eventually be DevMUD, I am questioning
the analysis/design strategy which have been "selected". So far, the design
strategy seems to be "assume nothing" and "design nothing" and "select tools
before analysis"... It think it would help a lot if the team forgot about
computers for a while and spent some time working on the vision (the
philosophy) and made sure it is related to the end product, MUDs.
--
Ola