Plugin architecture; was: [sldev] Avatar list ready for testing!

Andrew Meadows andrew at
Wed Feb 21 15:23:06 PST 2007

This reminds me of an idea I had a long time ago for a simple
plugin system for 3rd party scripts:  use the apache runtime environment
(APR) libs to add simple HTTP server capability to the SL client
such that it could send and receive XML data (incidentally, the SL
simualators already do this on their internal network).

Properly formatted XML could trigger the client to execute callbacks that
would trigger UI events, send SL packets, or reply back with XML packed data
such as: avatar position, inventory contents, or whatever.

Once a APR server were embedded in the client then
making a quick plugin would be pretty easy. Pick the data stream you're
interested, write some callbacks that supply the data on arrival or on request,
and send it out through localhost to a "local plugin" or even out the ethernet
port to an "external plugin".  The plugins could be in any language that
supported XML and network packets, and the client code would be OS agnostic.

I affectionately call this idea "tank treads" because I was pitching it as
a generalized solution to another developer's proposed feature (joystick input)
and someone made a comment to the effect:  "You're suggesting we build tank
treads when all we really need is a bicycle wheel."

The biggest disadvantage, as pointed out by one of the other LL developers,
is that without some sort of encryption (SSH), unguessable URLs (capabilities),
or other security measures this would be a wide open hole for all sorts of
exploits.  Even if the APR socket is on javascript can trigger
packets to localhost, so someone could set up a malicious website that could
take some control of any currently running SL client.

- Andrew

Tateru Nino wrote:
> Hmm. How about this? The plugin subsystem gets a feed of decoded 
> messages forked from the network handlers. It can either use some 
> interest-list/registration system, or just spew messages raw to the 
> plugin and expect each plugin to discard what it is not interested in - 
> as a preliminary measure. Additionally the viewer should be able to 
> inject messages of it's own, destined for the plugin subsystem. This 
> could indeed be done with a socket or local network port.
> The plugin subsystem in turn can generate messages to be injected 
> asynchronously back into the viewer, either to trigger the viewer itself 
> to take an action (make your own list of local actions and expand as 
> necessary), or to generate a message to return to the grid via the 
> data-stream (more based on what actions the viewer can take via the 
> network protocol).
>'s cheap. In its simplest form, its potentially grossly 
> _wasteful_, even. But heck, if you _really_ wanted a cheapass bot, plug 
> a python script, have it tell the viewer to 'stop rendering' (to save 
> all those CPU cycles, same as minimise mode), sit back and let python 
> drive.
> Potentially, it could be used as a stopgap for exploring just what sort 
> of facilities and layered interfaces you _want_ in a plugin architecture.
> Dale Glass wrote:
>> В сообщении от 21 февраля 2007 17:38 Mike Monkowski написал(a):
>>> But maybe you could answer a question I've been trying to figure out
>>> concerning the plugin discussion here.  I can understand in a browser
>>> how plugins can be inserted in the stream of data and act as a filter
>>> for specific file types.  Would this mean that the SecondLife plugins
>>> would be inserted in the message stream between the client and server?
>> Something like that, although considerable work is needed here. For 
>> example, take my scanner. It queries the avatar's payment info and 
>> birth date. Now, when the reply arrives, the client gets a packet of 
>> the AvatarPropertiesReply type. A plugin would have to register itself 
>> and say "Hey, I want to know when one of those gets received too". 
>> Except that in the current code there can be only one handler per 
>> message type, so that will have to be fixed.
>>> Or would they work off of the local cache?  Or would they reference a
>> Definitely not, there's not much you could do with that and it'd be 
>> ugly too.
>>> class that had accessors for each of the global variables?
>> A bit of everything would be needed. A plugin needs to be able to tell 
>> the viewer that it's interested in certain types of packets. It has to 
>> be able to access some internal state (avatar list, say). It's got to 
>> be able to do things like creating windows, sending commands to the 
>> sim, etc. Quite big changes are needed here.
>>> Mike
>>> _______________________________________________
>>> Click here to unsubscribe or manage your list subscription:
>>> /index.html
>>> ------------------------------------------------------------------------
>>> _______________________________________________
>>> Click here to unsubscribe or manage your list subscription:
>>> /index.html

More information about the SLDev mailing list