[sldev] Plugin API Architecture for Second Life

[John Hurliman]

Tofu Linden wrote:
> Sadly I think that discussion is quite orthogonal to the more important
> question of what the plugin API should look like, i.e. what
> functionality needs to be exposed to plugins and what the interface to
> that functionality should look like.  Once that interface is
> established, binding it to a scripting language is usually fairly
> straightforward.
>
> 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.  :)
>
> Kind regards,
> - Tofu!
> _______________________________________________
>   
>

Agreed. Talking about scripting languages really has nothing to do with 
the plugin architecture, as you can easily drop luaplugin.dylib or 
monoplugin.dylib in your Second Life folder *once there is a plugin 
architecture*. Here is my wishlist for the plugin system, in order of 
priority:

* Raw access to the messaging system. The ability to setup a callback 
for any packet that can suppress, modify, or pass through any packet 
before it is sent to the internal SL callbacks, and the ability to 
inject both incoming and outgoing packets.

* Create new menu items that hook to callbacks in the plugin

* Create new floaters (windows)

* Access to the OpenGL system


(Many of these have already existed for years through snowcrash.exe)

John Hurliman