|
|
| Line 11: |
Line 11: |
| # Implementations | | # Implementations |
| ## [[Plugin_architecture_Low-level Architecture|Architecture for direct dynamic library loading]] | | ## [[Plugin_architecture_Low-level Architecture|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.
| |
|
| |
| [[Category:Feature Requests]]
| |
Revision as of 20:11, 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
- Survey of Client Plugins as Potential Models
- Security Model Issues
- Cross Platform Issues
- PlugIns affecting Client Stability
- Plugin <--> LSL Communication Channels
- Implementations
- Architecture for direct dynamic library loading