[opensource-dev] Client Plugin System Design

[Rob Nelson]

As stated before, sockets add unnecessary bulk to any plugin
architecture, ESPECIALLY HTTP.  The SL viewer currently takes up 100%
CPU even with scripting turned off;  The last thing we need is more
memory or processor load.  

There are ways to signal the viewer when an event has occurred without
using sockets, and without running a separate process. A simple
std::queue of events being passed to the Lua engine is what I currently
use.  I therefore suggest C++ Dynamic Shared Objects, each providing a
language option (Lua, Python, Mono), but with a shared interface that:

 * Provides public start/restart/kill methods (for a scripting console)
 * Is in its own thread (to prevent blocking)
 * provides a way to pass in events with variable arguments (Luna uses a
string stream with serialized objects)
 * Provides the scripting engine some basic "environmental
variables" (Viewer name/channel/version, settings THAT ARE NOT
PASSWORDS, some other global vars like gAgent)
 * Automatically starts (if configured to do so) only AFTER login to
prevent receiving login details
 * Does not provide a way to create raw messages or send money.

There's probably a bunch of other requirements, too.  

If firefly is truly using Mono, then I do sincerely hope it fails.  Mono
is way too slow to run plugins efficiently, and as seeing that the
viewer is already chock-full of slowness, I don't want any more overhead
added.

Rob Nelson
Luna Viewer 
http://luna-viewer.googlecode.com/

On Wed, 2010-03-17 at 10:50 -0500, Argent Stonecutter wrote:
> On 2010-03-17, at 10:21, Dzonatas Sol wrote:
> > Ricky wrote:
> >> So far, barring any LL concepts, we have (as far as I know so far!)
> >> two designs of plugin system:
> >> 1: Socket-based plugins - as�suggested�by Morgaine.
> >> 2: D-Bus or similar existing IPC tool.
> >> 3: C++ Dynamically Shared Objects - my suggestion.
> >
> > 4. REST/HTTP
> 
> That's just a specific design for category 1.
> 
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges