The basic idea is to build 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, 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.

There will be 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 added eventually.

We'll sort out stuff from the discussion on MUD-Dev and summarize as time permits. See issues.html., and also the proposed intermodule protocol v0.1. or v0.2. for more details.

Things that need to be done soon:
	1) Improve intermodule protocol spec.
	2) Update prototype to match spec.
	3) Specify the modules for the first example MUDs
	4) code those modules

Jon Leonard