[sldev] Plugin system - first code drop

Tim Shephard tshephard at gmail.com
Tue Feb 27 12:58:13 PST 2007

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.

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.

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

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

On 2/27/07, John Hurliman <jhurliman at wsu.edu> wrote:
> 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
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html

More information about the SLDev mailing list