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 

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 :-)


Home | Subject Index | Thread Index