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

Tim Shephard tshephard at gmail.com
Sat Feb 24 02:27:25 PST 2007

For those who like to see code and specifics and dislike the
theoretical conversations, I'd like to propose two solutions that I
hope are somewhat specific in concept so they can be easily discussed.

The first one is inheritance across DLLs.

The idea behind this one is that people could extend llFloater (and
similar classes) in their DLL and then register that class with the
main UI Factory in SL.

Further hooks into the main message via macros that Bushing has
prototyped would allow intercepting messages.

SL itself could be broken up into DLL(s) and export functions which
the plugin could import to add to the message queue.   These functions
would just be ones that currently exist.

The advantage to this is that it would certainly get Dale's plugin up
and running very quickly.   I haven't seen the code, but I assuming
he's just extending llFloater or a similar SL UI widget as recommended
by the wiki.   Well placed macros could call his code where he's
updating his avatar list.    I assume there needs to be a way to
trigger a refresh of his UI (correct me if I'm wrong here) when new
information comes in.

The advantages of this approach is that it will work very well with
what LL currently has, it will even be a great way to get people
involved in the code base for future employment opportunities.

The disadvantage, and I think this is a big one, is that I'm not
entirely sure how stable this approach is or how cross platform it
might be (the attached proof of concept is win32 only).
Right now the biggest caveat you need to follow when doing this
approach is making sure all DLLs are compiled with the same options.

Questions for the DLL gurus:  do all dlls/so's/mac equivalent maintain
their own heap?  How are vtables implemented on the various platforms
and will it effect this solution?

The other solution is NPAPI, here is a link:


While I like is the simplicity of this model  I am concerned with is
that I'm not sure how it can enable Dale's plugin.


How does Dale's floater panel get drawn?
Do you have two UIFactories and loops?
Would it be like a flash or java plugin?

Possibly, we could export the widget drawing functions from an SL DLL
and then call those on an internal window.   Basically duplicate a
copy of the SL widget loop, but have it changed so that it is only
working on the internal window as described by the plugin.
Kind of a mini client inside the client.

Advantages:  simple, stable, hopefully not processor intensive or
memory intensive.
Disadvantages:  would require some re factoring of the UI system to
work on a sub window (I think).    Probably requires a seperate
thread, which may create costly problems as they do battle for the

We'd probably have to cut/paste the code and alter it in order to not
interfere with LL engineering / introduce bugs in to the core code

These are just two solutions and I propose them only for discussion.

I hope this will not discourage people from discussing other ideas,
such as the Separate Process / Proxy solution which I actually find
very intriguing.

Especially since it's ready to go, and because it will enable a
significant amount of stability in the client.  There is also a great
deal of experience with this project.  The concern, of course, is CPU
sharing between processes.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: inherit.zip
Type: application/zip
Size: 88515 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070224/890c0120/inherit-0001.zip

More information about the SLDev mailing list