DevMUD intermodule protocol, version 0.1.  Comment away!

Each module should have a short name, and export symbols with that as a
prefix.  The unique names are to allow static linking as well as dynamic.

A module named "name" would export these symbols:

int name_init(void);
int name_go(void);
struct interface *name_interface;

There may be a need for some more symbols, but they're not
present in this version.  Candidates include a version
number, a description string and a call to shut down the module.

Exporting symbols without the prefix is discouraged, but not formally
considered a bug unless a conflict arises.

What they mean:

name_init:
	This is the first function called after the module is loaded.  It
	should do any initial setup required before the module gets configured.
	If it returns anything except zero, it indicates that the module
	was not correctly configured, and should be ignored.

	Until name_init has been called, name_interface is not required
	to be valid, and calling name_go may do nonsensical things like
	crash.

name_go:
	Calling name_go tells the module that it has been correctly configured,
	and that it should start performing its in-game duties.  For example,
	a main socket module should open the socket in socket_go.  A return
	value other than zero indicates that something went wrong, and that
	the module may not be performing correctly.

	Modules writers should keep in mind that name_go isn't called
	simultaneously for all modules, so a module may be configured to
	work with temporarily unresponsive modules.

name_interface:
	This is an array of function-describing structures.

	The format should look something like:
	struct interface {
		char *name;		/* what the function is called */
		void *function;		/* a function pointer */
		char *prototype;	/* arguments to the function */
		char *description;	/* human-readable text */
	}
	Each (name,prototype) pair should be unique.  Multiple functions
	can have the same name in order to support some degree of
	polymorphism.  For example, a function taking text input might
	have two entries, one taking a Unicode string and the other an
	ASCII string.

	The prototype should contain enough information to verify that the
	function will be called correctly.  I'm envisioning something like
	"int(char*,char*)" as being the format string for a function taking
	two character pointers and returning an integer.  We should
	eventually write a verifyer program to check that these declarations 
	are correct.  Shorthands for various types (like "string" for "char*")
	should be developed, especially when it adds useful information.
	UTFstring might indicate a string required to be in UTF-8 format,
	for example.  A naive implementation might simply strcmp() prototypes
	to verify that they match.

	The description should be human readable if present, but may be
	NULL to indicate that a description isn't available.

	The array should be terminated with a {NULL,NULL,NULL,NULL} entry.

All of this specification is to allow the Config module to do its job.  The
only requirement for the Config module is that it not make bad assumptions
beyond what the protocol guarantees. 
