[sldev] Plugin system - first code drop

[John Hurliman]

Tim Shephard wrote:
> Thanks Richard.
>
> That was a real eye opener, especially the bit about "large
> architectural decisions to be made".
>
> Can you shed some light on that?   Are these decisions strictly GUI
> hierarchy related?   Timelines?
>
> My main concern here would be developing a contract of Ansi C function
> pointers across DLLs and then after the architecture upgrade is done a
> significant impedance mismatch occurs, and everyone needs to rewrite
> their plugins.     Or, worse, we keep you guys from doing the upgrades
> you need to do because you have to support a bunch of legacy
> plugins... ;)
>
> Heh.   I hope I'm not the only one that doesn't see the curious
> challenge trying to architect when you have no clue what the over all
> technical roadmap looks like...
>
> I am beginning to think whatever we come up with in this environment
> is going to be sub-optimal at best.
>
> Though I can imagine that we can probably come up with something that 
> works...
>
>

Continuing on with what Richard was saying, everything has changed, is 
changing, and will continue to change in the future. Second Life is more 
like a research project than a product, and expecting that you can write 
anything for it and walk away for two months and have it still 100% 
functional is completely out of the question. Forget about UI 
architectures changing, what if the functionality your plugin uses 
doesn't exist on the grid in another two weeks? What if the packets that 
you are intercepting and sending out are now using the REST protocol? 
With World of Warcraft plugins, every time a big functional change is 
made to WoW or the plugin API changes they bump a version number and 
every plugin breaks. The plugin developers take a look at the latest 
changes, adapt to them, and release again. It's not an ideal situation, 
it's probably not even good, but it works and in reality it's probably 
the only way to build a plugin system on top of something with such a 
rapid development cycle. I would focus on a versioning system for 
different components of the client, so if message_template.msg changes 
all plugins that send and receive packets break. If the UI system 
changes all plugins that have UIs break. Same for the rendering 
pipeline, etc.

Just throwing a wish out, but if the API exposed C functions instead of 
C++ that would make my day.

John Hurliman