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.
Mike
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.
L.
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:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting
privileges
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp
