Difference between revisions of "Plugin architecture"
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]] | ||
Revision as of 18:48, 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
- Discussions
- Required Changes
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.