MOO-cows Mailing List Archive
[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]
Re: plug-in interface
- Date: Sun, 20 Jul 1997 23:48:33 -0400 (EDT)
- From: Christopher Unkel <firstname.lastname@example.org>
- Content-Type: TEXT/PLAIN; charset=US-ASCII
Oh my--did I hear an invitation to insert my thoughts into a discussion?
Erik wrote, responding to Nick:
>> Some enhancements that might make this system adaptable to a wider
>> variety of plug-ins include the ability to "register" a function to be
>> called in the server main loop
> Can you (or someone else) give some examples of what this would be used
> for? That would help in coming up with a good design.
I'll take this one.
I've envisioned plug-in modules doing a wide array of things. Some examples,
ranging in ambitiousness, might include: adding simple built-in functions (a
la bf_list_assoc), FUP, adding a network implementation, adding a data type,
adding the source-level debugging facilities.
Some things that plug-in modules might want to do, from the programmer's
perspective, might be:
- register a built-in function
- call externally visible (non-"static") functions in the core source
- access externally visible (non-"static") global variables in core source
- *modify* functions in the core source (cause a different function to be
- insert a function call into the main loop, to allow periodic processing
(a network or file-utilty plug-in might want an opportunity to check
for i/o readiness every second)
- have functions in the library called at certain points in startup,
checkpoint, and shutdown (for example, a plug-in that performed the
processing functions normally in the startup script, or which caused
checkpoint files to be gzipped)
> Just to address a concern that might come up: I don't have any
> intention of making dynamic loading a prerequisite operating system
> feature for MOO. As far as I'm concerned, the API for dynamic loading
> should be pretty much the same as that for static extensions. So you
> will be able to "plug in" your plug-in at compile time if you can't do
> it at load time.
I think a good design would allow the most conventional extension modules
(adding a set of built-ins) to be used either as compiled-in modules or as
run-time loaded plug-ins from the same code base.
> Actually it might make sense just to have the config file's name and
> location specified in the command line, just as the database file is.
Perhaps plug-ins could be specified on the command line with first a
specification of the plug in, and then a single parameter for the plug-in
(probably used to specify a config file), like:
moo -p fup fup.cfg -p fooplugin fooplugin.cfg foo.db foo.db.new 7777
An alternative would be to store the config information in the database file
itself. In this case you'd probably want to have a config-only mode (or add
it to emergency wizard mode, or compile a separate binary, or whatever) for
modifying it so you don't have to start up the whole system just to tweak a
> My assumption is that there is a set of modules that is loaded at startup.
> This can happen _before_ the database is loaded, so there's no issue of
> corrupt data unless you start up the server _without_ a data type that
> you included last time. I think this is sufficient (provided there's
> a way to recover if you do eliminate a data type).
More generally, there may be a set of times at which it would be convenient
for some entry function to be called, like at startup, after database load,
just before program termination, etc.
One thing to keep in mind is that "dynamically-loadable library" tends to be
synonomous with "shared library", although the two aspects are substantially
different. Plug-in modules will most likely need an opportunity to
initialize, and later release, per-process (per-MOO) data structures. In the
case of Windows, the operating system does provide this opportunity, but the
plug-in may want certain information (e.g. version info) that could only be
provided by a defined hook in the plug-in interface.
Michael wrote, responding to Erik:
>On Wed, 16 Jul 1997, Erik Ostrom wrote:
>> 3. It's possible that we don't want new functionality to keep on filling
>> up the global built-in function namespace forever. It's been suggested
>> that plug-ins could take the form of "native objects" or "native methods"--
>> that is, from the database side, using a new function would look like
>> a verb call, but it would be implemented in C (or some other native-
>> compiled language). This may be orthogonal to plug-in design, but it's
>> probably worth thinking about some.
> This would be cool -- then native verbs could subsume the concept of
> builtins (which work poorly in an OO paradigm, in my opinion), and we
> could do away with the strange bf_protect mechanism as well. It would
> unify the builin/plugin mechanisms into a single modular concept. Have a
> verb flag 'n' indicating a verb is natively implemented. Map all currently
> existing builtin functions to (for example) $builtin:the_bf_name. If
> someone wants to wrap or protect a bf, then it's a simple matter of
> moving the native verb elsewhere and making the original $builtin:verb
If I'm not mistaken, Cold allows something similar. In this case, the
database should maintain information about plug-ins (the association from a
verb to a "native" method), rather than having a separate config file or
command-line parameters for the "plug-in"s. This seems to me like an
effective way to manage namespaces. With plug-ins the issues of colliding
built-in names become more serious than they are now (at the moment, if you
had extension modules with conflicting names, you could just do a trivial
source edit; if you instead had a plug-in module and no source, you could be
Some other thoughts:
1. Plug-ins should provide for version control, at least to the point of "I am
server version 1.8.0p6, can you work with me?" A system where both the plug-
in and the server have the opportunity to "approve" a combination would
probably be most flexible. Also, there should be the opportunity to provide
extended version information to the database users; I believe that Nick
advanced a proposal in the regards a while ago.
2. A natural thing to think about along with putting extension modules in
shared libraries is to put the core code in a shared library as well. This
can be more efficient if multiple MOOs are running (if code in the exectable
is not shared across processes but shared library code is) and can also make
sharing functions in the core code easier. The largest barrier to this that I
see is the large number of global and static variables; there needs to be a
copy of this data for each process using the shared library.
3. While we are on the topic of making it easier to add things to the server,
how about making it easier to create built-ins that suspend? I can see
several ways this would be useful, i/o functions like a non-blocking
open_network_connection() or non-blocking file-access functions being the most
ResComp Senior Network Support Technician (SNST)
Home Page: http://www-personal.engin.umich.edu/~cunkel/
This signature no verb.
Subject Index |