# Plugin interface

Michael Brundage (brundage@laurel.ipac.caltech.edu)
Thu, 17 Jul 1997 07:11:44 -0700 (PDT)

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    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