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

[Jon A. Lambert]

On  1 Nov 98, Ola Fosheim Grostad wrote:
> "Jon A. Lambert" wrote:
> > I think it's essential for bytecode modules that use the VM engine.
> > As for native code modules, should one be required to edit
> > the makefiles and relink the entire mud statically to effect a
> > change?
> 
> Think about it.  There is no real difference, automate the process if you so
> desire.  How slow is your linker?  This is clearly a minor issue for a mud
> development project, and no worse than editing a config file...

I'd rather just keep the mud running and issue a command to
reload the module.  All modules are not equal however.  Some modules
will be reloadable with no effects on the user base.  Some modules
being reloaded will have similar effects to that of a server boot.  
(Perhaps a period of lag while the mud waits on the module)
Having some modules be statically linked and some dynamically linked
introduces an unneccessary complication in the way maintenance is 
done.

Some of us have mentioned the desire to to have mud language modules
converted and optimized as native code at some point in the 
development process.   This would require reboots for converison to 
native and for any later maintenance on such modules.  

I also view configuration information as a candidate for runtime 
dynamism.  Another source of unnecessary rebooting.

> > 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.     

> This is getting worse. Now you don't even assume anything about the
> developers, and Vadim ignores the lag! Great! A total lack of a problem
> space!!  You'll be lucky if you eventually stumble onto something which
> isn't a minor issue...

I don't favor making assumptions on a particular issue in which the
design would make the assumption irrelevant.  Perhaps the command
to load the module should require to issuer to pass a programmer's 
quiz on linking.  Would that requirement satisfy the proposed problem 
space?

> The real challenge for the team is to actually form and communicate a vision
> which can act as common designgoal. It should address the potential
> developers using it, of how it is going to save the day for developers etc,
> on a conceptual level (not lowlevel technical level). I think this is
> imperativ for a volunteer collaborative effort. 

Dynamic loading saves the day.  No more reboots.  Kiss monolothic
inflexible statically linked mud servers good bye forever!

[Snipped Star Wars stuff]
  
> 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. 

> 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.  

> > > 1. there is no object model
> > 
> > Yes,  I know this does bother me a lot.  I think there are many
> > disconnects here between those of the function/data persuasion and
> > those of the object-oriented persuasion.
> 
> At least some sunlight! Not as much as I think would be appropriate for the
> process but still..

The questions have been raised.  There are two object models.  One 
is concerned with the server architecture.  The second model is the
one which the game design architecture utilizes.  I think I have the 
inklings of a solution that will satisfy many possible game design 
language models.  I think different object models (Self, Tom, Lisp, 
etc.) and those which lack of an object model (Basic, Fortran, etc,) 
can all be supported on the same VM.  A topic for another day
perhaps.   

> I guess I should refrain from further complaints, if implementing a "cool"
> feature fulfills a recreational purpose then trying to get a grip on the
> process is probably a total waste. Probably tells a lot about why the
> software industry does what it does though. :(  Almost as depressing as last
> years drive to log everything the users say just to hold it against them...

Should we make the logging module part of core functionality or have 
it as an optional module?  :P        

--
--/*\ Jon A. Lambert - TychoMUD     Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--