[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