Plugin System

The goal of this document is to create a draft proposal for a plugin system (aka. client-side scripting, mods, or add-ons).

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).

The design of the system can be naturally divided into three broad parts:


 * UI Widgets: C++ classes and XML schema for defining the visible layout of the interface.
 * API: Classes and methods that scripts can use to interact with the viewer and world.
 * Scripting Engine: The C++ backend in the viewer that runs the scripts.

The design and implementation of this system would be a very major, long-term project involving a team of at least 3-5 developers and designers. In order for this project to be at all feasible, it needs to be done incrementally, in small enough chunks that it doesn't become overwhelming. A working plan and roadmap are required. They don't need to be (and should not be) set in stone, but they must be there to provide a guide of what to do next.

Jacek Antonelli's proposed roadmap is this:


 * 1) Design and plan the details of the widget schema and API, and to a lesser extent the engine. (At least one month.)
 * 2) Revamp XUI, cleaning up the C++ code and XML schema to match the end target. The existing UI files would be updated to the new schema as we go; the UI should always work, and always be current. (One to two months.)
 * 3) Revamp the UI callback system, generalizing it and reworking it to resemble the end target API. Again, the existing UI would be continually updated. (One month.)
 * 4) Integration of a scripting language interpreter (e.g. Python, Ruby, something of that nature). This would just be enough to have a text console window inside the viewer where you could type commands to an embedded interpreter. No API yet, just standard libraries. Assume that additional languages will be supported later. (One to two months; this could overlap with the above work.)
 * 5) Gradually expose the API as classes/methods that can be tried out via the interpreter console.
 * 6) ... (More to be written)