[sldev] Plugin system - first code drop

[Richard Nelson]

What Ryan said...:)

Specifically, my best hope is that we can collaboratively decide where the extensibility points are in the architecture.  I just don't think the LLFloater class is it, but I'm willing to be proven wrong.  I believe we need to be careful in picking our extensibility points.  Build in too few abstraction layers and the code is brittle and non-extensible.  Too many, and you get COMtamination.  Right now, I'd say we were on the side of too few.

Over the past months, we have gradually introduced abstraction at key points in the architecture.  Data abstraction is handled via LLSD and UI layout will eventually be entirely handled by our XML files.  One question we haven't fully answered is how the data "model" and ui "view" will talk to each other.  Others use data binding languages such as XBL/XAML combined with scripting languages such as ECMAscript.  We currently use C++ classes that derive from LLPanel and LLFloater...probably not the best choice for the long term.  Whatever we settle on will not only affect the customization of our UI, but most likely any plugin system as well.

There are many other architectural decisions to be made, such as how do we multi-thread the UI and have it update asynchronously with respect to the renderer framerate?  It would also be nice to cache UI elements into textures and perform lazy updates instead of drawing into the framebuffer every frame.  How much do we integrate HTML into our UI or base our UI on HTML?

I can't give you a long-term schedule for these features and design decisions, because I have none.  This is not even an official list, but more of my perception of the general consensus.  We are hiring like mad, and the open source community can contribute significantly here, so let's figure this out.

Richard

On Wed, 28 Feb 2007 13:00:29 -0800, Ryan Williams <rdw at lindenlab.com> wrote:

> To alleviate this, I think the most important thing code-wise is keeping
> things as modular as possible.  The current viewer is pretty bad in this
> regard, but there's no reason that new code can't be good about it.
>
> -RYaN
>