[sldev] Approach to accessing floaters from inside plugins

[Soft Noel]

On Thu, March 8, 2007 7:01 pm, Dale Glass wrote:
> 2007 07:36 Soft Noel:
>> I'm working to simplify the Floater interface for the C plugin
>> interface, proceeding along these lines. Input on the approach would be
>> appreciated before I start widening the interface with more events and
>> accessors. The explanation will be in three parts. The first is what a
>> plugin author would see/use. Here's enough interface to create something
>> like the sample "Hippo" floater from the wiki:
> [snip lots of cool stuff]
>> This is a thin vertical slice of the UI. More widget types will be
>> added, as will manual callback removal, window hiding, etc. What I want
>> is input on whether this is the type of interface we want to give plugin
>> authors.
> That looks really neat, but does that mean you're going to expose the
> whole
> SL API as C functions? That sounds like a lot of work.

I want to expose as much of the API as is reasonable for some basic
plugins, then focus on areas where people explicitly need functionality to
accomplish things.

I'm convinced that for plugins to be taken seriously, they will need to be
reliable across multiple versions of the viewer. If plugins can break on
very short notice with each SL release, businesses will be hesitant to get
behind plugin projects, and the second-tier platforms (Mac and Linux) will
more often get left behind. If plugin stability restricts viewer
development, LL will be more hesitant to accept plugins in the shipping
viewer. To me, this only leaves a (hopefully thin!) abstraction layer as
the only choice. I'd love other ideas here.

Without the resources to tackle this for the whole SL API, it will make
sense to expose some of SL's objects natively later on, but with the
understanding that this should only be for specialized projects that are
only expected to work with a single viewer version.


> And what are you going to do about things like LLString, LLVector3, the LL
> abstractions for file access, etc?

Unfortunately, passing class-based objects around will expose dependencies
on specific versions of those objects and limit language choices. Some of
these will have to be copied to generic structs and we may want our own
C-based string functions.

Also, the pushback against C++ in favor of C has been strong. I haven't
heard anyone but myself come down on C++'s side so far, so I've gone C for
the interface. LLString and the stream objects are incompatible with that.


> I haven't had time to think on what you said properly yet, though. Hope to
> do that this weekend.

More input is always appreciated - helps lots!