[MUD-Dev] Re: DevMUD Objectives?

[Chris Gray]

[Niklas Elmqvist:]

 >Well, with a module-based system, you would *never* (at least not in a
 >perfect world) have to reboot your server even if you add changes. All the
 >functionality of the MUD is contained in the modules which are dynamically
 >loaded at run-time, so adding new stuff is as easy as recompiling the
 >module, unload the old one and load the new one into the executable.

I think you are maybe being a teeny bit optimistic there! If you replace
a module, you replace the code of that module. That works for some
kinds of modules, but not for others. For example, replacing the
telnet module is likely a bit rough on the existing telnet connections.
Perhaps we need a way to phase modules out as uses of them are replaced
by uses of a replacement. That could be done with a "please go away"
request to a module, and it goes away when it is ready to do so. In the
meantime, a new module which exports the required interfaces has been
loaded and gets all new connections.

The big problem is that of state. Many modules will have state attached
to the characters, NPC's, etc. For example, if you want to replace, say,
a combat module, with one that has a more detailed combat model, you
could be in trouble. This is strongly influenced by the model used for
objects, persistency, the database, etc. If objects have static structure
like C++ and Java objects do, this is hard to accomplish. You'd have
to detect out-of-date objects, and migrate them to the new form. This
would result in both forms being present for some unknown time. If,
however, your object structure is dynamic (or not even a structure, but
more just a flexible array of property-value pairs like mine), then
adding new data values is fairly easy, as long as the system allows you
to have a default for it (on mine, you just set the default on the
appropriate ancestor, and all descendants instantly have it). Deleting
data values (e.g. to replace them with a computed one) is as easy as
ignoring the values. If you want, you can have a chunk of code in the
new module that detects the now-unneeded fields and deletes them.

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

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA