Description of the modules that currently make up Aber++:

AberchatClient
  The client for Aberchat. When initialised it opens a socket to the aberchat
server and requests authentication. The process loop handles messages coming
from aberchat and acts upon them. On shutdown it simply closes the socket
to the server. The other functions are mainly concerned with sending messages
to the aberchat server. It's not complete, mainly because I haven't written
enough of the Avatar (aka character) class to send results from, say,
amudlist back to a single person.

Assembler
  Handles assembling files from files on disk, and also translation of
bytecode to C++, which it puts in data/test.cc. Also has methods to resolve
symbolic object and class names to UniqueIds, which should be moved out
to the Object and Class DBs.

ClassDB
  Holds all the class information in a group of arrays - currently there
are 10 arrays - one for system classes that never get passed between
muds and have a consistent interface across all muds, one for the local
mud's classes, and the others for classes transferred from other muds, needed
to make sense of objects taken into the mud from other muds.

ClientSocket
  A generic client internet socket - OS dependent, the one currently in there
is BSD-flavoured (i.e. Linux). Has functions for sending and receiving both
null-terminated data (for aberchat, mainly) and null-terminated data.

EmailClient
  This is an experimental client for sending email to people - currently
it connects to tcp/ip port 25 on the local host to send mail, so it'll probably
only work on unix systems. Also it doesn't do any error detection.

Environment
  Keeps track of environment variables, which are currently loaded from
data/<name of mud>.cfg. It guesses the name of the mud from the hostname of
the machine the mud's running on (set from ListenSocket).

Kernel
  This starts up the mud, calling init methods on things like databases
and services, has a process method which calls the process methods on those
modules which need it (like Processor and TelnetService), and a shutdown
method to close the modules down.

Library
  This provides virtual machine library functions (equivalent to OS functions
called by trap in assembly languages). Note that the actual library code
goes in lib/ - for any given library module, the files are <name>.lhc,
the handler module that actually does the calls, <name>.lrc which turns
a library function name into a string representation of the module and
function number (used by the assembler), and <name>.lhh which gives help
on a given function.

List
  A linked-list template class which Sloat wrote for Leviathan II and which 
I've borrowed and slightly modified to allow changing the pointer at a
particular position in the list.

ListenSocket
  A generic non-blocking listening socket, which accepts connections and
returns a ServerSocket, or 0 if no-one's trying to connect. Also gets hostname
information when people connect. All Service modules are likely to have
one ListenSocket initialised at startup.

LogonDB
  Keeps track of which users are logged in from which hosts to which
objects, and what their privileges are(these will eventually be used to
determine if users can become other objects (like become <x> in traditional
Aber) and maybe for some other things. Haven't decided yet).

Mud
  Keeps some useful defines and the global variable theworld, pointing to
the world definition

MudAddress
  Defines the address of a mud service. Not used much yet.

MudClass
  Defines a mud class, containing pointers to mud methods. Also has info
on properties defined and which class is the class's parent.

MudMethod
  Defines a mud method, with pointers to either native C++ code or bytecode
to implement the method, and necessary information about numbers of locals
and constants defined. There should be a mechanism to deal with what
arguments a method takes but isn't.

MudObject
  Defines a mud object - basically a bunch of mud variables and a pointer
to the class type.

MudVariable
  Defines a mud variable - basically it can consist of a long int, a
string, an array of pointers to mud variables, a list of the same, or a
uniqueid (i.e. pointer to a mud object/class/method/property). Possibly
should have different types for class and object pointers. Also has
functions to convert the variable to and from strings for transfer and
storage. Note that the use of strings probably means we don't want people
declaring huge lists and arrays in mud code.

NameClient
  A client needed by every mud which connects to the nameservice and
authenticates users.

NameService
  This will only be needed by one mud in the Aber++ network eventually -
it holds information about users like their password and object. It should
probably eventually run on a 'mud' without a nameclient, telnetservice
or object and class databases - i.e. a dedicated server. There's no provision
for a fallback name service running on another mud yet.

OSUtils
  OS-dependent utilities like getting the system time.

ObjectDB
  Keeps track of all objects loaded - the division is the same as for classes,
one array for system objects, one for local objects, the others for objects
which have been transferred from other muds (e.g. players who've moved to
this mud and their equipment).

Opcode
  The class that defines a bytecode opcode.

Opnums
  This has lots of defines of the form #define <opcode name> <opcode number>
which I've used to make VirtualMachine and Assembler more readable.

Peers
  The peers database will be used to keep track of which mud services are
where - where to find, say, Isis mud's RPC service or telnet service. It's
updated by the NameServer at present. Note there's no reason why a mud
couldn't be implemented with different services in different places. The
current code isn't written to do it but future code could be and would work
with the existing muds. Note also it isn't properly implemented to keep
track of different services and ports, at the moment it just keeps track
of mud name/UniqueId mudnumber equivalencies.

Processor
  Manages the virtual machines, and handles things like task priorities.
Is called by the kernel and in turn calls all the virtual machines. A priority
of -1 on a process, incidentally, means that the process is given all the
time it needs - this is probably not safe and will need to be changed to
prevent the possibility of the mud being locked up. Note that task priorities
aren't properly implemented yet.

Registry
  Keeps track of which services and clients are defined and what their
status is. Will be used by code to determine if things they need are compiled
into a given mud.

ServerSocket
  Handles a single incoming connection. Has methods to send and receive
null-terminated strings, and has a flag to deal with telnet connections as
opposed to non-telnet client connections which I might eventually use to
make the mud work properly with windows telnet. That's not implemented yet
though. It also maintains a stack which keeps track of which MudMethod should
be called when data is received from the socket.

SocketDB
  This provides a C++ stream-type interface to MudMethods - a stream
(aka Socket for historical reasons ;) can be a ServerSocket, a file, standard
out or a custom handler defined in a MudMethod. It's anticipated characters
will have a socket handle passed to them on connection which they can then
use for output. Possibly characters should have a list of handles in order
to support more than one person seeing what's being sent to a character
(e.g. for snoop).

String
  The GNU String class's header. I'm not sure, actually, whether this isn't
the whole string class defined inline like List, in which case we won't
have to write our own for other platforms.

StringBag
  A List of Strings. Used as an abstraction for blocks of text like files.

Syslog
  System logger. Has various different priority messages, and for each
priority maintains a list of SocketDB streams to send the data to. Currently
it defaults to sending all messages both to stdout and logs/Mudlog, but
there's no reason it couldn't send different categories of log message to
people logged on as well (or even MudMethods).

TelnetService
  Takes care of people telnetting in, authentication from the NameService,
and connecting them to objects.

Translated
  Keeps track of all bytecode that has been translated into C++. Note that
the actual code is #include'd from trans/. The idea is that each class
will have native code in trans/<name>.tcc, and every time a new function
is translated an administrator will check it to make sure it isn't malicious
then do cat data/test.cc trans/Avatar.tcc > trans/Avatar.tcc, and add
an entry for it in Translated. Some provision will need to be made for
multiple translated methods awaiting concatenation with the trans/ files,
probably by making the temporary file name based on the method name.

UniqueId
  Defines a 'pointer' to a mud object, mud class, object property, or mud
method. The reason this is used rather than a real pointer is that it can
be saved to and from disk and transferred between muds. Might slow things
down though. It consists of three numbers - a mud number (0 for system
things), an index into the class or object db, and an element number used
only for identifying properties or methods and ignored when finding classes
or objects.

Utils
  System-independent utilities, mostly file-related. Some of them are
a bit hacked-together and/or probably in the wrong place, and the
class/object file routines should probably use load_file not direct file
access (meaning they can eventually be used cope with files transferred
from other muds without an intermediate write to disk).

Varlist
  An implementation of the List class for mudvariables with a few useful
extra functions to cope with indexing.

VirtualMachine
  A non-multitasking virtual machine, capable of coping with mixes of
bytecode and translated C++ functions.

World
  A class which defines lots of pointers to things like databases and
services, which is pointed to by theworld and is used by the kernel to
run the mud. Theoretically there could be separate worlds, all of which
processed by the same mud code - this would effectively give you several
muds sharing the same code, which might save memory.






