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

dirk husemann hud at
Thu Feb 22 06:41:14 PST 2007

Jason Giglio wrote:

> > Andrew Meadows wrote:
>> >> 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.
> >
> > I don't see that as the biggest disadvantage.  XML is a hell of a lot
> > of overhead for something that's local, that you control both ends of,
> > and that is going to potentially be pushing data with high transaction
> > rates and strict latency requirements.  That's a huge hit just to be
> > buzzword compliant.
i like the idea of having a localhost TCP interface through which
plugins can asynchronously inject /receive pakets. i have my doubts as
well with regards to XML, but on the other hand, if we keep string based
(instead of going binary) you could have a shell script implement a plugin!


> > This assumes that we should accept new plugins on the fly, without
> > restarting the client.  I'm not sure that's a reasonable design goal.
> > If plugins were totally asynchronous like that, how would you start
> > them when SL started?  Or should they sit there as little daemons or
> > services whenever the system is booted, just waiting for SL to start?
how about having a plugin starter in the client (in the worst case that
could be done as a shell script prelude to starting the client itself)
that goes through a .secondlife/plugin.d directory and starts all
plugins in that directory in alphabetical order (00-plugin-1,
05-plugin-2, ...). on shutdown the client will just send a "GOOD NIGHT"
message out over the socket interface --- causing the plugins to shutdown.

you could even make the port number random: the client (or prelude
script) picks a random available port number, passes that in to the
secondlife client, and also as a startup argument to the plugins. add a
randomized password (generated anew for each SL session) and pass that
in to the client and plugins and it becomes rather difficult to run an
JS XMLHTTPRequest attack...


-- dr dirk husemann, pervasive computing, ibm zurich research lab ---
hud at --- +41 44 724 8573 --- SL: dr scofield

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url :

More information about the SLDev mailing list