[sldev] Plugin system - first code drop

[John Hurliman]

Tim Shephard wrote:
> Another way to deal with the chaos is to develop a layer which shields
> the plugin developer from a majority of it.
>
> ie:  instead of tight bindings to the current UI architecture, we
> could loosen it up.  A layer of facades that are divorced from the
> current system and plugin facing contracts will not be majorly
> impacted by changes to the core code base.
>

 From what I have seen in the last year of SL development, it might not 
even be worth it to try. No matter how abstracted away things are, it 
only takes one functional change in how things work to break plugins. If 
a plugin is utilizing something that no longer exists in a new version, 
it's not going to work until changes are made to the plugin.

> Provide the  client with a bit of an internal capabilities API, so if
> something is not longer present, they can detect it on startup / on
> the fly.

It could work in theory, but it would have to be fairly complex. To 
throw an example out there, you used to be able to send ViewerEffect 
packets without specifying an AgentID or SessionID, which made for a 
mild but entertaining exploit. I implemented the libsecondlife 
ViewerEffect functions to work against what currently existed, and wrote 
some SLProxy code against what currently existed. After reporting the 
exploit, the next release fixed the problem which meant a protocol 
change. The ViewerEffect packet was still called ViewerEffect, it still 
worked in the exact same way, but there were new required fields where 
the packet wouldn't work if they didn't exist. libsecondlife had to be 
updated and the SLProxy code had to be updated to reflect that. Unless 
the "internal capabilities API" either attached version numbers to every 
packet, or had a way of analyzing code to make sure that every field is 
set properly it would have no way of detecting whether an OpenSL plugin 
was using ViewerEffect correctly. You could always abstract away from 
every packet and make a proxy interface to building each packet, but 
with over 500 packets (the exact number changes almost every release) 
it's not feasible.

It might be beneficial to define a set of goals and determine a 
cost-benefit for them, and then go back and reassess the goals. A goal 
of making an interface where plugin developers never have to update 
their code is not going to be reasonable. A goal of having plugin 
developers only have to update their code every month or so might be 
attainable in some circumstances, but how much work would it take to 
maintain an interface like that, versus the amount of work it would take 
for plugin developers to keep their code up to date?

>
> Also, if things are going to be getting busted so much, I believe this
> means that  dynamic on the fly, behing the scenes updating of plugins
> is becoming more critical.   Users  should be able to get updates
> without feeling the  upgrade pain, cause it sounds like they'll be
> feeling enough as it is..

I agree completely. Something like the Firefox model where it 
automatically checks for updates and can install them almost painlessly. 
There's no reason to put the burden of development on the end users as well.

>
> Also, I hope we don't let this "all is chaos" approach become an
> excuse not to have a dialogue with the Lindens.   That would be
> awfully unfortunate..

Aren't we having a dialog right now?

John