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

Ola Fosheim Grøstad <olag@ifi.uio.no> Ola Fosheim Grøstad <olag@ifi.uio.no>
Mon Nov 2 12:42:24 CET 1998

"Jon A. Lambert" wrote:
> > > I can distribute my native module in binary form to another DevMud
> > > user, who can simply add a few parameters to a configuration file
> > > and, viola, they're using my module.
> >
> > Yes, if you assume that the commercial developers which the DevMUD
> > project were supposed to cater for are totally incapable of programming, but
> > then again, what do they need this for then. They could just run off with
> > diku, muq, moo, lp, cold + a wide range of startups.
> To the contrary,  dynamic loading makes no assumptions about what
> abilities are required to load a module.

Huh?  Generally, all features costs. Therefore, focus on needs and identify
problems in the early stages...  But then again, this seems to be a
religious issue, and I see no reason to keep nagging.

> > Actually, you'll probably get a lot of split objects, state stored multiple
> > places etc etc. What you really should do was to at least identify modules
> > that would be needed in a full mud and spec the requirements to see what the
> > implications are.  Not really my choice, but a lot better than discussing
> > bolts and nuts for "nothing".
> Well, this discussion was about glue.

You don't know what "glue" is most appropriate unless you now some more
about what kind of traffic you get.

> > Besides, "all" programs are optimized by the programmer, it is just a matter
> > of how far you are willing to go.  If you don't optimize for MUDs then you
> > could happily do with any dbms on the market, etc, etc.  To optimize for
> > MUDs you have to know something about structure and dynamics.
> An optimized database for a Diku would be completely different
> than an optimized one for an LP and even moreso for a Cold.   So MUDs
> don't have any optimizations in common in this area.  This is a big
> reason why "modular" design is so important.

Pfft. There is no one medicine that would cure all diseases.  Actually, I
think MUDs have a lot in common when it comes to the object system and
dynamics, compared to other areas (webservers for instance).  What is
basically wrong is that you think too hard about implementation before you
have tried to explore the consequences of hard modularization on example


More information about the mud-dev-archive mailing list