[sldev] Plugin system - first code drop
tshephard at gmail.com
Mon Feb 26 23:26:52 PST 2007
> > 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.
OK, that concern makes sense. However, looking through the code,
llFloater seems likely to be very resistant to change. If it does
change, it would likely impact a very significant amount of code and
therefore would only occur when absolutely necessary.
Perhaps a linden can comment..
> 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.
By this, I understand that you mean that the derived class would sit
in the core code base and changes to it wouldn't necessarily impact
the plugin api / function pointer table which is the real contract.
I agree. This is important as that contract should be ideally
near-perfect and very resistant to change as it would be the function
pointer table loaded from the DLL that the plugin developer exposes
and relies on.
> 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.
I think you're saying here that plugin developers would create a
plugin-side class and would export that class or at least its
individual functions to the core code base.
That seems like an ideal approach if you can expose the functions in
the plugin to the core code base in a safe way.
However, my understanding is the best way to expose across dlls is
with C extern stubs rather than classes, even if no inheritance goes
C++ has a lot of mysterious things happening which I'm not sure
translate very well on a cross platform basis. Not being a cross
platform expert, I certainly can not comment confidently.
It would be also interesting to see a proven example with a history of
working that uses classes across DLLs.
However, that being said, it would be nice if someone had the cross
platform expertise to proof of concept that if they had the sufficient
motivation to do so. It might be an opportunity to make history in
the world of plugin architectures... :)
I included a win32 proof of concept for exposing classes across DLLs
in a recent attachment on a previous email, so they could start with
Thanks for the comments Soft. You're really moving all of this
forward very rapidly. I hope your contribution is well recognized :)
More information about the SLDev