Plugin architecture; was: [sldev] Avatar list ready for testing!
hud at zurich.ibm.com
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
>> >> 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 zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070222/f369edec/signature.pgp
More information about the SLDev