[sldev] Client-side viewer plugins possible?
Argent Stonecutter
secret.argent at gmail.com
Mon Nov 19 07:40:32 PST 2007
The process of designing a client-side plugin model has been started,
or at least discussed, several times.
I've seen a few issues get in the way.
First, and most importantly, is that Linden Labs needs to be actively
involved, because a plugin model would need to be supported in the
Linden viewer and it would need to be stable. They are a pretty busy
bunch, and maintaining stable APIs is already a pretty big problem
for them, so it's understandable that they might not care to add a
new one.
Second, there's the question of the API. A C or C++ API would allow
for the "deepest" plugins, but a higher level API (through a
scripting language, for example) would allow for cross-platform
plugins, and a service API (through a local TCP connection, or by
calling helper applications that would communicate through stdin and
stdout) would allow any language to glue in. Personally, I like the
Tcl C bindings, but Lua and Javascript have also been suggested.
Third, and this may not be an issue for you, there's licensing. The
open source client is using a modified GPL, which means plugins need
to at least be open source, though not actually GPL (thanks to the
FOSS exception). Whether is matters to companies trying to sell
plugins depends on circumstances - if they can use a service model or
they're just writing importers for data from a separate product that
wouldn't be an issue.
More information about the SLDev
mailing list