[SERVER] Plug-in server extensions

• Date: Sun, 27 Oct 1996 14:27:52 PST
• From:
  Christopher Unkel <cunkel@us.itd.umich.edu>
• Reply-To:
  Christopher Unkel <cunkel@us.itd.umich.edu>
• Content-Type: TEXT/PLAIN; charset=US-ASCII

This has been sitting in my postponed messages folder for quite a while
now; I thought I'd send it and see what commentary I could get before
proceeding to more specific implementation issues.


Okay, having recieved a fair amount of harrassment about adding FUP
support to WinMOO, and being unwilling to simply add it as a command-line
option (lest MOO become like gcc: "-frtti -fhandle-exceptions"), I am
going to consider what things should be present in a reasonably flexible
MOO "plug-in", or run-time-linked, system.

My acid-test for this system is this: it should be sufficient to enable a
FUP implementation.  A more strenuous test might be that the system should
be sufficient to implement a dynamically linked *network*
implementation--but I'll leave well enough alone for now and stick to FUP.

For the moment I'll call the plug-in module a DLL.

The design parameters I've come up with are, in no particular order:

1. The DLL needs access to all the utilities in the server.
Fundamentally, this is everything that is specified as external linkage in
a header file.  The DLL needs all the facilities in the server, from
memory management, to network input and output, to DB interaction, etc.

2. The interaction between the server and the DLL must include version
control.  Because a DLL uses all the externally linked functions of the
server, it is either linked to a specific version of the server, or needs
to be aware of the differences among versions.  Therefore, the version of
the server needs to be available to the plug-in at load time to verify
compatibility.

3. Version information about the installed plug-ins must be available to
the user.  It should appear in the log file in a standard format for
diagnostic purposes, and should be available during run time via a
built-in function.

4. While the DLL must be able to call a large number of functions in the
server, the server needs to call only a small number of predefined
functions in the network implementation.  Specifically, the server must
call the DLL:
A. At startup to give the DLL an opportunity to perform initialization,
register built-in functions, and to obtain version information.
B. At shutdown to give the DLL an opportinity to clean up.
C. When the server needs to call the built-in functions registered by the
DLL.  However, the server doesn't need to know where to find these
functions; the plug-in tells it this when it registers the functions (as
in the current extension registration procedure.)

5. Plug-ins must be initialized before the database is loaded or function
calls will be unneccesarily converted into calls to call_function().

6. Variables with external linkage may need to be encapsulated by a
function or functions for plug-ins to access them, and should be
encapsulated regardless for portability where these mechanisms have been
altered (for example).


Additional design considerations are:

1. Portability, part I.  The extension mechanism should be portable to as
many systems as possible..  This is difficult because run-time linking is
one of the least standard mechanisms across platforms.

2. Portability, part II.  The extensions themselves should be as portable
as possible.  This presumably involves a good packaging to insulate the
server and extension alike from the dynamic-link implementation.  The
plug-in design should facilitate use of plug-ins as traditional
compile-time server extensions when dynamic linking is unavailable.

Comments, anyone?


  --Chris                           cunkel@engin.umich.edu
    ResComp Network Support Technician, Bursley Hall
    "Invisibility is in the eye of the beholder."
    Home Page: http://www-personal.engin.umich.edu/~cunkel/

• Prev: [SERVER] Extended internal data types
• Next: [solved] Linking Rooms
• Index: MOO-cows
• Thread: MOO-cows