MOO-cows Mailing List Archive
[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]
Re: Plugin interface
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
non-native.
For a concrete example, consider the current bf set_verb_code().
This would be moved to a native verb $builtin:set_verb_code(). If you
want to change its behavior (for example, to acquire an in-db lock on
the object when modifying one of its verbs, or to add in-db VCS support)
then you would move this native verb to, say, $wrapped:set_verb_code(),
and write the wrapper code as a non-native verb $builtin:set_verb_code()
[which now calls the wiz-protected $wrapped:set_verb_code() to do the
native work; I suppose $wrapped:set_verb_code() would check wiz-perms or
whatever in its native implementation to enforce this wiz-protection].
How the server handles loading the native code would have to be worked
out (e.g., there's no point in loading in all DLLs for native verbs
until they're used; can they be unloaded in low-memory conditions; if
the native implementation is modified at run-time, when does the server
clue in to this; etc.), but that's a SMOP :-)
michael
brundage@ipac.caltech.edu
References:
Home |
Subject Index |
Thread Index