[sldev] [AWG][OGP] generic client plugin/scripting API
lenglish5 at cox.net
Wed Dec 17 09:48:38 PST 2008
Mike Monkowski wrote:
> Gack! You lost me with the first word of your title: "generic." I
> believe that is a very naive approach. Unless you are specific about
> what kind of functionality you want to provide you will quickly get
> lost. Can I plug in a new render engine? Can I add a plugin that
> requires new message formats? Can I plug in mesh based objects? Can
> I add a plugin to create a local sim on my machine?
> As you say, people (many who are familiar with web page design, but
> have never looked at the viewer code) have been talking about the
> mystical plugin/scripting API forever. When you start with the word
> "generic" you're just encouraging chaos.
Well, that's the thing. Why can't it be generic, at least on some level?
It's true that rendering plugins would be more difficult to make generic
than, say, IRC plugins, but there are bound to be features applicable to
any SL-compatible client, or you wouldn't be talking about a SL plugin.
Right now, all the existing clients are either based directly on the GPL
code or are reverse engineered to be compatible with the GPL code at the
protocol level. What is wrong with trying to keep this compatibiltiy at
the plugin level by abstracting away differences? That includes
abstracting the existing GPL code as well since its the least extensible
and flexible of all the viewers out there.
> Lawson English wrote:
>> all the various Second Life viewer developers are (and/or have been)
>> talking about a plugin/scripting API. Here's a discussion in the
>> Imprudence forum that describes a system that is coincidentally close
>> to what I'd like to see made available in the pyogp viewer. ...
> Policies and (un)subscribe information available here:
> Please read the policies before posting to keep unmoderated posting
More information about the secondlifescripters