[sldev] Plugin API Architecture for Second Life
tshephard at gmail.com
Mon Feb 12 21:10:30 PST 2007
On 2/12/07, John Hurliman <jhurliman at wsu.edu> wrote:
> Tim Shephard wrote:
> > I believe bushing has mostly been using callbacks in functions in the
> > open sourced code and then loading libraries dynamically via
> > LoadLibrary/GetProcAddress.
> > This is certainly one approach, and an interesting one, but there are
> > many others which have different pros/cons and trade offs.
> > For example, what do people think about embedding a virtual machine
> > something custom?
> > What security and stability issues are people concerned about?
> > Is cross platform support critical?
> > Do you think LL should support different frame rendering plug ins or
> > should we keep it so that everyone in SL always sees the same thing
> > when viewing the world?
> > Should we be able to communicate back and forth with LSL programs from
> > the plug in?
> > Any particular favorite plug in architectures out there that you think
> > would be a good model for Second Life?
> > Any other comments people might have?
> > Cheers,
> > Tim.
> I don't think it's necessary to embed a virtual machine directly inside
> opensl, since you can always write a plugin to do that. I think cross
> platform support is important so plugins aren't restricted to only OSX
> users, there is a lot of people using SL that aren't running macs.
For my own selfish purposes, I agree with this statement.
However, to make sure the discussion is complete and that we're not
simply rushing ahead, I think there is some value in thinking about a
plugin architecture which doesn't allow for open ended linking in the
client .. I just want to make sure we're all aware of the sacrifices
we're making by losing some of the 'stability and security' (quote
quote) that the current client, unsullied by plugins, provides..
> John Hurliman
> Click here to unsubscribe or manage your list subscription:
More information about the SLDev