Plugin architecture; was: [sldev] Avatar list ready for testing!
gigstaggart at gmail.com
Wed Feb 21 16:48:57 PST 2007
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
> 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
> 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
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.
More information about the SLDev