[MUD-Dev] My vision for DevMUD

[Jon Leonard]

This is my perspective on a DevMUD project, and is of course open for
discussion.  Were I elected/appointed/defaulted project maintainer now,
this is how things would get done.

I'm interested in building a MUD server which is well suited to development
of experimental MUD features.  Support for commercial use, optimized
implementations, etc. are secondary.

>From this goal, I think some decisions follow:

1) The code should be composed of modules, so that features that are not
   relevant to the specific expiriment at hand can be excluded.  This
   also allows for alternate implementations.

2) The licence should by default be public domain.  This provides the least
   impediments to using the code for experimentation.  Allowing some modules
   with different licenses is useful for reusing existing code.

3) The code should be well documented, and where possible easy to understand.
   This is also for ease of making expirimental modifications.

4) There should be more than one example collection of modules, as not all
   expiriments would use the same starting point.


There are a few other decisions that affect modules in a project of this
type.  In particular, I prefer:

Implementation Language:  C for maximum portability and flexability.  To the
	extent that modules in other languages can intermix with C modules,
	other languages should be usable.

Threading:  The minimal inplementation should not be threaded.  Not all
	target platforms support threading, and requring thread support
	from all modules makes the system significantly harder to
	understand.  If a particular collection of modules is thread-safe,
	they should be usable as a threaded server.  Note that a threaded
	virtual machine model does not require a threaded server.

Garbage Collection:  Without special arrangements, modules are responsible
	for maintaining their own storage.  (Using a Database module is
	such an arrangement.)  No global GC-friendly practicies are mandated.
	Again, this is to make it easy to understand and add to the server.

Module interfaces:  Modules should export a predictably named array of
	function information structures, and a separate verifier program
	should be available to check the accuracy of type information.
	Modules should be dynamicly loadable (on platforms with support)
	for maximum flexability.  There should be a method for describing
	interfaces for interface inheritance.

In general, features should not be required of all modules, nor should the
overall design preclude features.


General DevMUD structure:

There should be a generic bootstrap loader, whose responsibility is to
provide module loading facilties and little else.  It is responsible
for loading a more specialized config module, which has responsibility
for loading and configuring the rest of the modules in the system.  A
typical config module will probably qickly delegate control to a script
in an in-mud language.

I envision at least two demo MUDs:

LP style, consisting of the following modules:
bootstrap	starting up
config		initial configuration
socket		raw network communication
telnet		network protocol layer
VM		executing in-mud language code
compiler	turning in-mud source to VM code
filesystem	storing in-game objects

Diku style, consisting of the following modules:
bootstrap	starting up
config		initial configuration
socket		raw network communication
telnet		network protocol layer
world		object and room interactions
parser		user commands
custom		extra code for customized objects
storage		saving what state persists

Other demo structures should be easily added...

I have more thoughts, of course, but that's generally where I'm coming from.
I'm volunteering to be project maintainer for such a project (including
hosting on my server), including writing some usable collections of modules
if necessary to jumpstart the project.

Jon Leonard