Difference between revisions of "Plugin architecture"

From Second Life Wiki
Jump to navigation Jump to search
Line 6: Line 6:
## [[Plugin_architecture_survey|Survey of Client Plugins as Potential Models]]
## [[Plugin_architecture_survey|Survey of Client Plugins as Potential Models]]
## [[Plugin_architecture_Security|Security Model Issues]]
## [[Plugin_architecture_Security|Security Model Issues]]
## [[Plugin_architecture_Low-level Architecture|Low-level architecture]]
## [[Plugin_architecture_Cross_Platform|Cross Platform Issues]]
## [[Plugin_architecture_Cross_Platform|Cross Platform Issues]]
## [[Plugin_architecture_Stability|PlugIns affecting Client Stability]]
## [[Plugin_architecture_Stability|PlugIns affecting Client Stability]]
## [[Plugin_LSL_Communication|Plugin <--> LSL Communication Channels]]
## [[Plugin_LSL_Communication|Plugin <--> LSL Communication Channels]]
# Required Changes
# Implementations
## [[Plugin_architecture_Low-level Architecture|Architecture for direct dynamic library loading]]


== Required Changes ==
== Required Changes ==

Revision as of 19:09, 12 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.

Table Of Contents

  1. Discussions
    1. Survey of Client Plugins as Potential Models
    2. Security Model Issues
    3. Cross Platform Issues
    4. PlugIns affecting Client Stability
    5. Plugin <--> LSL Communication Channels
  2. Implementations
    1. Architecture for direct dynamic library loading

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.