[sldev] Two potential plugin architectures: Inheritance across DLLs and NPAPI

Tim Shephard tshephard at gmail.com
Sat Feb 24 10:00:36 PST 2007

Well, the question is how much the plugin will call back into the main
code and how much it will simply provide an API for the main code to

It would be easiest (in some ways) if we could just provide an
interface for the system to call and the DLL does not have to be aware
of functions in the main client.

We could create floaters by create llFloaterProxy or llFloaterPlugin
and then use a Decorator pattern (ala GOF) to implement the behaviour
of the proxy floater.

Unfortunately, everything keeps twisting back into a requirement to
call code in the main code base.   This might be doable for simple
classes that are stateless, however I am concerned that at some point
it starts getting more complicated, less stable, less cross platform
and more crash prone.

If we do export functions to be used in the Plugin DLLs, we may want
to export C methods only rather than C++ classes.

On 2/24/07, Dale Glass <dale at daleglass.net> wrote:
> В сообщении от 24 февраля 2007 17:06 Tim Shephard написал(a):
> > > Client is patched to call LLFloaterAvatarList::updateAvatarList() every
> > > frame, which then goes over LLCharacter::sInstances and updates its
> > > internal list.
> >
> > This is one of the problems with this style of architecture.. rather
> > than simply invalidating your widgets and asking the UI control to
> > redraw, you have to poll yourself very rapidly.   This isn't ideal
> > from a performance point of view.
> What do you mean?
> It doesn't HAVE to update itself every frame. It's just that the code that
> updates the internal list runs every frame because I made it like that. I
> could make it be every 5 frames instead, or time it to be every second.
> Skipping frames wouldn't have been good for the people with low framerates.
> And since it doesn't seem to have a noticeable effect on framerate anyway, I
> just left it like that.
> The UI doesn't get updated if it's hidden, too.
> The alternative to this would be getting events "avatar Alice moved", "avatar
> Bob appeared", etc. But the update of the internal list has very little
> performance impact anyway, so that'd be too much complexity for very little
> benefit.

More information about the SLDev mailing list