Difference between revisions of "Plugin architecture"
Jump to navigation
Jump to search
Rob Linden (talk | contribs) |
|||
| Line 8: | Line 8: | ||
## [[Plugin_architecture_Dynamic_Loading|Dynamic Updating and Loading Of Plugins]] | ## [[Plugin_architecture_Dynamic_Loading|Dynamic Updating and Loading Of Plugins]] | ||
## [[Plugin_architecture_Cross_Platform|Cross Platform Issues]] | ## [[Plugin_architecture_Cross_Platform|Cross Platform Issues]] | ||
## [[Plugin_architecture_Stability|PlugIns | ## [[Plugin_architecture_Stability|PlugIns affecting Client Stability]] | ||
## [[Plugin_LSL_Communication|Plugin <--> LSL Communication Channels]] | ## [[Plugin_LSL_Communication|Plugin <--> LSL Communication Channels]] | ||
# Required Changes | # Required Changes | ||
Revision as of 18:42, 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.