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

[Jason Giglio]

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 127.0.0.1 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.

As for security, I don't see that as totally intractable.  There's 
already a level of trust required for plugins themselves, so the main 
concern is an exploit, like JS XMLHTTPRequest like you pointed out.

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?

Plugins only loaded when the client starts would prevent some random 
exploit from initiating a connection to the running server, since the 
client would know what connections it was expecting and from what plugins.

-Jason