Difference between revisions of "Plugin architecture"
| Line 25: | Line 25: | ||
= Calls from viewer to plugin (hooks) = | = Calls from viewer to plugin (hooks) = | ||
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. | 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. 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. | 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. | ||
| Line 48: | Line 48: | ||
* 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. | * 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. | * Add internal callbacks for events such as rendering a frame, receiving a chat message, etc. | ||
=Other Information= | =Other Information= | ||
Revision as of 19:03, 14 February 2007
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.
Some technical challenges for creating a plugin architecture are as follows:
Low Level Architecture
In order to override or enhance existing functionality in the viewer, we need to be able to replace some code with our own.
Loading Dynamic Libraries
Ideally, most interesting functions in the viewer would be broken out into dylibs / dlls so that plugins could link against them. This is possibly the best option for the long term but will require a lot of work moving certain existing client features into their own dynamic libraries.
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:
- libtltdl
- Glib GModules
Function Pointer
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.
Calls from viewer to plugin (hooks)
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. 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.
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