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.

dlopen code example

There are wrappers to allow this to be more cross platform:

• Apache APR - Already in use in llimage/llimagej2c.cpp. Not GPL compatible, but is compatible with the GPL+FLOSS exception license used in the Second Life viewer
• libtltdl
• Glib GModules

Making the client into dynamic libs itself

Most interesting functions in the viewer could be broken out into dylibs / dlls so that plugins could link against them. Code that we want to be able to call from a plugin needs to be in a DLL, and they can all be in the same DLL. Code that is so rarely used we'd like to not load it unless we have to should go into a separate DLL.

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.

hook example code

hooking sending IMs

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.

One solution is to pick a number of useful functions, build a function pointer table, and allow plugins to ask for them by name.

function pointer example code

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.

• Affecting rendering pipeline (eg, improving rendering of clouds)
• Transforming messages (eg: adding encryption to IM messages)
• Improving the User Interface (eg: better building tools)
• Automated Agents, potentially headless (no GUI).
• Extend client to support new 3D object types and their behaviors (eg: rendering of objects with complex, non-primitive shapes or complex behaviors)
• Extend client to be a platform for other applications (eg: PDF viewer with scrollbars on the face of a prim)

More Plugin Architecture Ideas

1. Development Road Map
2. Discussions
   1. Survey of Client Plugins as Potential Models
   2. Backwards Compatibility
   3. Security Model Issues
   4. Plugins affecting Client Stability
   5. Plugins <--> LSL Communication Channels
   6. Closed Source versus Open Source

1. Alternatives
   1. Embedded Virtual Machine With Scripting Language
   2. Separate Process