[sldev] Plugin API Architecture for Second Life
sldev at bushing.mm.st
Wed Feb 14 17:04:03 PST 2007
On Feb 14, 2007, at 2:25 PM, Rob Lanphier wrote:
> On 2/13/07 3:11 PM, Ben Byer wrote:
>> @ Linden Lab:
>> It sounds like splitting chunks of the viewer code into
>> dynamically-loaded chunks is a win-win situation:
>> * Plugins could then link against that code
>> * Dynamic chunks could be updated without disturbing the rest of the
>> * The same mechanisms could be used to create plugins
>> * Infrequently-used functions (estate manager, etc?) could defer
>> loading until they're actually needed.
>> Given that I can't sign a code-contribution agreement, how can I help
>> with this effort?
> That definitely puts a damper on things in general. If you can't
> to contribute code or ideas to this effort, then I think writing
> against whatever we come up with/reporting bugs is the next step.=20
> However, even using the bug tracker or wiki requires agreement to the
> contribution agreement there.
> I suppose I need to turn the question around. How do you feel you can
> best help? Also, what about the contribution agreement is
I didn't say that I couldn't agree to contribute code or ideas to the
effort, or that I wouldn't do so; I said that I can't sign the
"Second Life Viewer Contribution Agreement".
I work for a fairly large organization doing professional software
development, mostly on open-source projects. Contributing to BSD-
licensed codebases has historically been acceptable, but anything for
which I would have to sign a release would require our Legal
department's review of the document, as well as executive approval.
Once you've gotten a handful of busy people involved in this
decision, it becomes a risk / benefit assessment -- what is the
benefit of allowing Ben to hack away on some "game" vs. the potential
risk of signing some legal document which could have some unforeseen
Stepping back to the present, "minor" contributions are fine -- small
patches, build fixes, bug reports, etc, are fine. (Basically, things
that don't rise to the level of being "worth" something, taken
individually.) I wouldn't be surprised if you hesitate to take my
word on that, but it doesn't bother my conscience.
Historically, I've been very involved in the libsecondlife project,
and helped start opensecondlife.org. I've written some code for
libsecondlife, but if you go looking for it, you won't find it --
it's all been rewritten, which is fine with me. Much of it is like
the plugin code I posted on the wiki; slightly crude, slightly
hurried, generally intended to show a possible approach rather than
be a final solution.
Beyond some trivial non-trivial coding, I've done a lot of
infrastructure work -- for libsecondlife, I set up the SVN repo and
moved it 3 times; I wrote the cron script that used to pull out the
message template and keywords file using gdb so that we could keep
libsecondlife compatible with the main grid whenever a new version of
the viewer was released. (Yes, #libsl, I know it's currently
More recently, I helped set up opensecondlife.org; I set up the SVN
tree there so that people would have a place to collaborate on code
that was not yet mature enough to be submitted back upstream to
Linden Lab; I set up git and Mercurial repos in the hopes that people
might start using those while we waited for an official LL SVN. I set
up OpenGrok to give 3rd-party devs a better way to grep through the
massive amount of source. I helped write build scripts to make it
more practical to build and rebuild official releases of the
SecondLife viewer. We threw the releases and build scripts into SVN
to make it easier to collect the pieces together, and started working
on a "tinderbox"-like continuous integration solution, to speed up
development. Since Mercurial never caught on, I started helping
resync our trunk with every new Linden release, but eventually left
that thankless, painful task to people more qualified.
Apparently everyone thinks that was a waste of time; I'm told FOSSL
was started because OpenSL was too hard to build (?) and with the
intent to "minimize divergence from the Linden Labs code to ease
merging and patching". (Best of luck with that.)
Linden Lab seems to see it as at best a waste of effort that could be
better spent writing up bugs and patches and wiki entries (*), or at
worst some sort of threat-to-fork; really, it was / has been / will
be an attempt to fill in the cracks and provide services that aren't
practical for Linden to provide to the community. Or maybe I'm just
tilting at windmills.
(*) I guess I actually can't do any of that. Oops.
More information about the SLDev