[Prev][Next][Index][Thread]

# [SERVER] Plug-in server extensions

- Date: Sun, 27 Oct 1996 14:27:52 PST
- From:
- Reply-To:
- 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

Home | Subject Index | Thread Index