Plugin System
From Imprudence
Contents |
Introduction
The goal of this document is to create a draft proposal for a plugin system (aka. client-side scripting, mods, or add-ons). This effort was begun on December 13, 2008; its primary contributors have been Jacek Antonelli and Morgaine Dinova.
Your feedback and involvement are welcome in the Development Forum.
Contents and Related Links
Sub-pages:
See also:
Background
From Jacek Antonelli's post in the forum thread that kicked this off:
I agree (believe me, I do) that a major architectural shift towards modularity, plugins, and client-side scripting would be extremely beneficial to our ability to mod the bejeezus out of the UI. I think World of Warcraft provides a great example of how such a system promotes UI experimentation and customization.
Blizzard made the choice to offer an API (using Lua as the scripting language) and XML schema for UI widgets. The result is that the community has created thousands of AddOns to offer improved user interfaces. Some of them are general improvements (easier inventory management), and some are specific to player classes (e.g. better access to spells for the magic classes).
One could easily see the same thing happening for SL: new UIs to help builders or scripters, for example. LL has already provided an XML schema for UI widgets, XUI (although it's not as nice to use as Blizzard's at the moment; that can be improved). There is a basic system in place for callbacks from that UI, which could be extended to become a proper API accessible from one or several scripting languages. It's feasible in theory, and by doing it in swallowable chunks (which I consider vitally important for volunteer projects).
Proposals for SL client-side scripting, mods, plugins, add-ons etc have had a long history ... in fact, as long as SL has existed and has run a public forum with Feature Suggestions.
More recently, the Multi-Process Client proposal laid the ground for a massively refactored client that is built entirely from discrete independent processes, and discussions in the UXIG SL group examined a relatively minor refactoring of the viewer to handle only scripting for HUD and widgets. Hopefully ideas can be cherry-picked from such proposals (and earlier ones) for the actual design adopted.
Timeframe and Roadmap
The design and implementation of this system will be a major, long-term project involving a team of 3-5 developers and designers. However, the full system will not be implemented and released all at once; rather, the core system and a partial API will be implemented first, and then expanded and fleshed out over time.
