[sldev] Plugin API Architecture for Second Life
dale at daleglass.net
Tue Feb 13 11:05:38 PST 2007
В сообщении от 13 февраля 2007 18:20 Rob Lanphier написал(a):
> On 2/13/07 2:19 AM, Tofu Linden wrote
> > The question behind that of exposed functionality should be: what
> > do people anticipate doing with such plugins? 'Everything' is perhaps
> > not a very useful answer for initial API planning. :)
Oh, I have TONS of ideas for plugins. I'm sure other people have ideas too.
IMO, plugins are especially good for estoteric functionality. For example, I
have something of an obsession with information -- if there's something I
could know I'd like to have it displayed. But I doubt LL would integrate most
of my additions into the main client, as quite a few of them would have quite
Other examples would include things like client-side versions of HUD
attachments. At the time, HUD attachments are seriously limited in what they
can do, and suffer from latency, update problems, LSL memory limits, etc. A
> Starting with a concrete example that came up during discussion at my
> office hour on Friday, I'd like to figure out how to make it possible
> for Dale Glass to ship his client scanner (see forwarded email below) as
> a plugin. This would involve the following:
> * Minimal plugin management (e.g. a set of conventions on where plugin
> dll/dylib/so files should be located, maybe some initialization file
> conventions, and a dialog which lets people know what plugins are loaded
> and running in their viewer.
Since I appear to be one of the first people working on something that would
work well as a plugin, I would appreciate if somebody could tell me which
people are working on the plugin system. I think it would be good to discuss
how to make the functionality my plugin would need available, and of course I
would convert my code into a plugin when it becomes possible.
> * Stabilization of important interfaces to enable this functionality,
> breaking out that functionality into a separate dll/dylib/so file. In
> Dale's case, an example would the API to our XUI user interface layer.
> * Other hooks/interfaces that give access to useful functionality. I
> think Bushing sums up the options well here:
In case somebody is interested (especially people implementing plugins
functionality, here's what my code currently requires):
* XUI (obviously)
* Knowing the logged in user's current position
* Access to list of known users. Currently done by scanning
LLCharacter::sInstances every frame, but a callback based approach that would
notify of new and disappearing avatars would also work, and probably save
some CPU time as well.
* If using LLCharacter::sInstances then I need to be able to run code during
every frame, to detect changes.
* If using callbacks, then I still need the ability to periodically run code.
A timer callback would work.
* Ability to measure passage of time
* Sending messages. Specifically AvatarPropertiesRequest.
* Receiving the reply
* Setting a beacon on an avatar or a location (LLTracker class)
* Finding when an avatar is producing a sound
* Ability to interface with an in-world scripted object. Until a specific
method is created, it would be by speaking on a channel and filtering replies
* Ability to detect when avatars are rezzing, generating particles, or using a
* Ability to read/write files, probably in XML
* Ability to save/load settings
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070213/775b3f28/attachment.pgp
More information about the SLDev