[sldev] Two potential plugin architectures: Inheritance across DLLs and NPAPI

[Argent Stonecutter]

> The idea behind this one is that people could extend llFloater (and
> similar classes) in their DLL and then register that class with the
> main UI Factory in SL.

The absolute deal-breaking potential gotcha with this one is, as you  
say, portability.

> The other solution is NPAPI, here is a link:

There are other similar APIs, this one has the advantage that it's  
probably already in the client through the Gecko engine. It has the  
disadvantage that there's a big old security hole waiting for us: if  
you register a plugin with this it could potentially be invoked  
without your knowledge by HTML provided by an attacker (say, in  
someone's profile) with parameters supplied by the attacker, rather  
than being invoked by the user through their plugin preferences pane.  
If it's used, utmost care is required.

There's two common approaches to a plugin API. They both start the  
same way... the plugin has some well-defined function name that's  
used to initialize it. Where they differ is how you register callbacks.

With some, the callbacks are implicit in the names of functions. If  
your plugin has a PLUGIN_foo function, then you're providing the foo  
callback.

With others, you explicitly register every callback in the  
initialization routine.

NSAPI seems to be the former.

I prefer the latter, because it's more stable over the long term, and  
more portable. The names you use to register the callback are  
independent of the language you write the plugin in, and they're not  
subject to the restrictions of third party code like compilers,  
librarians, and other parts of toolchains.