[sldev] Re: Plugin architecture
monkowsk at watson.ibm.com
Wed Feb 21 15:24:28 PST 2007
Tateru Nino wrote:
> The plugin subsystem in turn can generate messages to be injected
> asynchronously back into the viewer, either to trigger the viewer itself
> to take an action (make your own list of local actions and expand as
This is what got me confused in the first place because the "list of
local actions" would probably have to be expanded to include every
method in the code base. And then you may as well just write your
function as part of the code base.
If the goal is to be able to write routines that do not need to be
compiled into the code base, then it should probably be done by
expanding the functionality of LSL scripts.
If the goal is just to keep the executable file size small (does anybody
really care?), then that might be achieved by compiling in a stub that
provides direct access to needed data and methods and dynamically links
in a library containing the bulk of the functionality if the function is
an entry in a customizable user's menu.
So what is the reason for having plugins anyway?
More information about the SLDev