[sldev] Plugin system - first code drop

Soft Noel soft at softnoel.org
Mon Feb 26 23:02:50 PST 2007

On Mon, February 26, 2007 9:50 pm, Tim Shephard wrote:
> Ahh, not so much looking for a full patch.. just perhaps an example of
> how you're doing this and what your thoughts are.

Gotcha! Actually, Bushing has a very nice, succinct example of hooking IMs:

Mine's more complex because I'm building it around a system that supports
interface versioning, similar to my LLJack/LLBundle work.

> The key, I think, is to make sure that the plugin developer has to do
> as little work as possible and that we add minimal technical risk to
> the client in use today.

Fully agreed. The quickest way we get the friendly API is to (a) find
something similar we can copy, or (b) run ahead with a couple simple
plugins, knowing we'll have to iterate over the implementation a few times
and throw some work away. I'm still looking for (a) while I (b).

In the end, the user friendliness aspect will probably happen more on the
plugin SDK library side, while the design of the client<->plugin interface
places primary focus on remaining unobtrusive to the client code. This
means, for a very basic example, that the sys->PrintLog() function you see
in the HelloWorldPlugin example would probably be replaced by a complement
of functions doing formatted printing, etc, which all back end to the one
call. This also lets us more rapidly evolve the plugin development
environment as we can iterate on releases of the plugin SDK independent of
the viewer.

> What I'm thinking is something along these lines (rough example):
> Basically we extend llFloater with a class called
> LLFloaterPluginProxy.   It would roughly be implemented as follows:
> LLFloaterPluginProxy::LLFloaterPluginProxy()
> :   LLFloater("floater_plugin")
> Basically there would be an instance of LLFloaterPluginProxy for every
> plugin floater created.

I initially rejected the derivation idea, as a class derived from the
floater class meant that this class would change any time the floater did.
What I didn't think about was that this derived class would be used by the
plugin and remain 100% viewer-side, it wouldn't be -part- of the plugin
interface (now "jack" in my code) itself.

I've got more thinking to do. The rest of your example is inspiring. I'd
hoped to sleep tonight, but it's clear that I'm going to comb over the UI
code so I can think about a layer implementation instead of just facing up
to it as a client. :(

One tempting approach is to more or less replicate the LLFloater interface
inside the plugin SDK, with the floater proxy as a bridge between the real
and plugin implementations, boiling things down to the simplest
representation of events and data changes that can be expressed through
LLJack versioned interfaces.

> The advantage of this approach is we don't touch core code, which I
> personally think is critical.


>  Not just for getting merged, but also
> to ensure we minimize risk to the client that are not using plugins.


> Let me know what you think, Soft.

Mulling this over a bit more, but I may run with it. :)

More information about the SLDev mailing list