Plugin architecture
As of this writing (February 12, 2007), there's not an official plugin architecture in the Second Life viewer. However, there's been a lot of interest in developing one. This page (and the pages it links to) are an attempt to capture a lot of the informal discussion that has occurred so far.
These are the three main issues to be addressed:
Code loading
Dynamic loading of natively-compiled executable code can be accomplished with dlopen / dlsym in Linux and MacOSX and LoadLibrary on Win32.
There are wrappers to allow this to be more cross platform:
- Apache APR - Already in use in llimage/llimagej2c.cpp
- libtltdl
- Glib GModules
Calls from viewer to plugin (hooks)
In order to override or enhance existing functionality in the viewer, we need to be able to replace some code with our own. One way to do this would be to install "hooks" into commonly-used functions. In the example implementation code below, you can hook any function by adding 'PLUGIN_HOOK("function_name", data1, data2)' to the top of the function.
When that macro is called, it looks to see if any hooks have been registered with a name that matches "function_name". If so, it executes each one in turn.
Each hook function can affect program execution in one of three ways:
- Pass event through -- a function might decide to ignore this hook based on the contents of data1 and data2, or it might do something which doesn't disrupt the program flow (such as adding data to an internal list for later use, or displaying a dialog box). In this case, it should just return TRUE.
- Modify params, pass event through -- as above, except the hook function can modify the contents of data1 and/or data2 before returning TRUE
- Swallow event: Sometimes, we want to completely override the function being hooked, for various reasons -- in this case, the plugin should return FALSE.
PLUGIN_HOOK executes each function in turn; if it function returns FALSE, it just issues a 'return' in the context of the hooked function. If all hooks return TRUE, control will eventually be passed to the hooked function.
Calls from plugin to viewer (exposing an API)
Most plugins will want to call into the client and have it do things like display dialog boxes, send IMs, etc. Unfortunately, there's no simple way to do this.
Ideally, most interesting functions in the viewer would be broken out into dylibs / dlls so that plugins could link against them. This probably isn't practical.
The alternate solution is to pick a number of useful functions, build a function pointer table, and allow plugins to ask for them by name.
Required Changes
Some changes in the code will be required to support plugins.
- Complete GUI and other classes with functions that would be expected to exist, but don't because nothing needed them yet. For instance, add method overloads that should logically exist.
- Allow multiple callbacks per message, as well as unregistering a previously registered one. Currently only one callback can be registered per message type.
- Verify that all the callbacks work in such a way that they wouldn't be confused by plugins. When a callback for a reply to a request runs it must make sure that the data to arrived is what was requested, and if not, ignore it.
- Add internal callbacks for events such as rendering a frame, receiving a chat message, etc.
Other Information
Capabilities and Plugin Examples
The following is a discussion of what we'd like to be able to do with a plugin. Note it is not a discussion of how plugins will be managed.
- Effecting rendering pipeline (eg, improving rendering of clouds)
- Transforming messages (eg: adding encryption to IM messages)
- Improving the User Interface (eg: better building tools)
- More..
More Plugin Architecture Ideas
- Development Road Map
- Discussions