[sldev] Plugin API Architecture for Second Life

[Dale Glass]

В сообщении от 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 
specialized purposes.

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:
> https://wiki.secondlife.com/wiki/Plugin_architecture_Low-level_Architecture
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

Future requirements:
* 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 
with llOwnerSay
* Ability to detect when avatars are rezzing, generating particles, or using a 
gesture
* Ability to read/write files, probably in XML
* Ability to save/load settings


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070213/775b3f28/attachment.pgp