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

[Tim Shephard]

The other idea for NPAPI, might be to create a shadow UI object in the
main code base, call it llFloaterPlugin, and the virtual methods of
that llFloater child would call out to procs which are exported by the
plugin itself.

When the SLPAPI function calls the plugin on initialization, it would
call out to a list of these floaters and their function sets and how
they're initiated by the user (eg, global keystrokes, menu items,
etc).

This probably wouldn't be too hard to do from where we stand right now.

On 2/24/07, Tim Shephard <tshephard at gmail.com> wrote:
> 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:
>
> http://web.archive.org/web/20040203102018/devedge.netscape.com/library/manuals/2002/plugin/1.0/intro.html#998197
>
> 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.
>
> Questions:
>
> 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
> CPU.
>
> 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
> base.
>
> 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.
>
> Cheers,
>
> Tim.
>
>