[MUD-Dev] DevMUD module configuration

[Jon Leonard]

As I was putting together a prototype this weekend, I realized that we
don't yet have a sufficiently flexible scheme for configuring modules
when we assemble them into a server.

The most sophisticated system I've seen described involves having each
module have a list of dependencies and other requirements, along with
a list of features that it provides.  The loader would then be
responsible for picking out modules to load when some feature is required,
pointing out conflicts, and so on.

The problem with this is that there are quite a few collections of modules
(that I'd like to see, anyway) which are ambiguous or otherwise fail to
correctly initialize in such a scheme.


For example, suppose I have three modules:

1) Socket, which provides network communication privliges

2) Telnet, which sits on top of Socket to provide Telnet protocol
    features and RFC compliance.  It has the same interface (or
    a superset), for mix-and-match capability.

3) World, which provides all of the non-transport functionality of a MUD.

When loading World, how does the driver know whether to load telnet or not?
Similarly, if Socket, Telnet and World are loaded, how does the loader
know to connect World to Telnet instead of to Socket?


A more complicated example, involving multiple games in the same server.
The modules are:

1) Socket, as above
2) Telnet, as above
3) ParserA, a command parser
4) ParserB, an alternate command parser
5) World1, a gameworld
6) World2, an alternate gameworld 

I want players to be able to use either gameworld, and for one run I
want ParserA to go with World1, and ParserB with World2.  The problem
is, the next time I set up the server, I may want ParserA/World2 and
ParserB/World1.  There's no way that the loader can figure this out.


As a result, I have a new proposal.

In addition to the special Bootstrap module (the only module known to always
be part of the server), there is a special Config module.  The Config module
is like any other module, except:

1) There can only be one Config module in a server.

2) The Bootstrap module automatically loads Config on startup, and passes
   control to it.

3) The config module is responsible for requesting modules to be loaded and
   telling loaded modules which other modules to use in which ways.  It may
   delegate this responsibility. 

I expect most Config modules will immediately load a game language module
and delegate responsibility to a program in that language.  This allows
great flexibility including command-driven reconfiguration during run time,
while allowing minimal Config modules for simpler MUDs.


More details about the prototype mentioned above:

In order to get a different perspective on how modules might fit together
to make a MUD, I threw together a prototype.  (There's nothing quite like
a segmentation fault to tell you that there's something wrong with a
design.)

It's missing some important abstractions, and I don't expect any of the
code to survive into a distributable DevMUD.  Much like my IPC example,
it only has two commands, "say" and "quit".  It does, however, use
dynamic linking and separately compiled modules to build a runnable mud.

It's running at mud.slimy.com on port 2121, and the source can be found
from http://mud.slimy.com/devmud/ by following the proto_1 link.
(The name mud.slimy.com isn't very special: Mud.slimy.com = frost.slimy.com
= devmud.slimy.com, etc.)

Jon Leonard