[sldev] Re: Plugin architecture
seg at haxxed.com
Sat Feb 24 01:06:38 PST 2007
On Fri, 2007-02-23 at 20:37 -0800, Rob Lanphier wrote:
> On 2/23/07 7:37 PM, Callum Lerwick wrote:
> > The proper thing to do is bless, say, OpenSL as the de-facto non-linden
> > fork, and keep everything merged into the OpenSL tree as much as
> > possible.
> The proper thing for who to do?
The proper thing for those interested in implementing features that LL
is not. That was the context of my reply.
> > ...this whole plugin thing is hilarious. Everyone's sitting
> > around shooting their mouths off about hypotheticals, and no one is
> > writing any code.
> I agree that a lot of talk and no code can be frustrating.
I'm not frustrated. I'm amused.
> If you know exactly what needs to be written, then I'd suggest you give
> it a shot. Since we don't really have a consensus at Linden Lab how
> plugins should work (that I'm aware of),
I don't know what needs to be written, YOU don't know what needs to be
written, no one else at LL knows what needs to be written. That's the
point. You start with what you do know, and you go from there.
> I'm kinda skeptical that you'd get it right on the first crack.
Exactly. No one in the world is going to get it right on the first
crack. It doesn't happen that way. It just doesn't. That is why
expecting to have a complete design done before writing any code is a
waste of time, because your design is going to be wrong. Guaranteed.
Embracing this reality is the essence of "Extreme Programming" or "Agile
Development" or whatever they're calling it these days, as well as being
a cornerstone of open source development.
"Design is not something that you do only before you code.
Implementation is not the act of coding."
At this point the plugin architecture is a solution looking for a
problem. YAGNI. Its all a pointless waste of time until there's an
actual need. Not a hypothetical one. Once there's an actual need, the
way forward becomes clear. Just write code, the rest will follow.
> If you're up to the job of maintaining
> your own fork, fine, but if you expect us to incorporate it, you might
> want to check in with us before sinking a ton of time into it. One
> thing that's challenging about this particular piece of functionality is
> that Linden Lab would be expected to support whatever emerges for quite
> a while, where some people may even expect bug-for-bug compatibility of
> the interface in perpetuity. We don't plan to bend to every unrealistic
> expectation of every developer out there, but I think it's fair to
> expect at least some degree of interface stability. Therefore, I
> seriously doubt that we'd incorporate anything without serious
> deliberation on the subject.
The real point I'm trying to get at, is that the thinking behind plugins
here is an artifact of close source development. Its Windows thinking.
One person has admitted that the only reason they want plugins is so
they can weasel around the GPL, shun the community and release
proprietary code. Is this what Linden Lab wants? Proprietary extensions?
If so, why was it licensed under the GPL rather than something BSDish?
Proprietary plugins are completely and totally antithetical to the
purpose of the GPL. Linden Lab has decided to share their source code
with all of us, under the terms of the GPL. If you think you have any
right to benefit from the viewer source without sharing with the
community, you're wrong. Unless LL has granted you a different
> Regardless, would you please be respectful and courteous?
Sorry, I'll try and tone myself down a bit...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070224/e2d353e3/attachment.pgp
More information about the SLDev