Plugin architecture

Required Changes

Some changes in the code will be required to support plugins.

• Complete GUI and other classes with functions that would be expected to exist, but don't because nothing needed them yet. For instance, add method overloads that should logically exist.
• Allow multiple callbacks per message, as well as unregistering a previously registered one. Currently only one callback can be registered per message type.
• Verify that all the callbacks work in such a way that they wouldn't be confused by plugins. When a callback for a reply to a request runs it must make sure that the data to arrived is what was requested, and if not, ignore it.
• Add internal callbacks for events such as rendering a frame, receiving a chat message, etc.
• It would be very useful to be able to communicate with plugins from LSL. For example, selecting an object or playing a game and having that object or game send status messages to the plugin for further manipulation, scoring, display, etc. This will require the ability for an avatar to have his client register a listener with the servers other than channel 0. The client would not display messages on channels other than 0, but would send them to any plugins which have been registered to listen on those channels.

Plugin <--> LSL Communication Channels

Many compelling applications would benefit from a pipe between the plugin process and server side LSL scripts. Anything which wants to communicate status or information which can only be gathered reliably via LSL rather than typical protocol messages the client receives would benefit from such a pipe.

A brief discussions on the alternatives for communication follows:

• Ideally, this pipe could be written differently from the current chat channels afforded by llSay or Instant Message, to avoid performance and size limitations. However, an early implementation using available technologies would be preferable to one which may take significantly longer.

• A chat channel implementation would require the ability for an avatar to have his client register a listener with the servers on channels other than channel 0. The client would not display messages on channels other than 0, but would send them to any plugins which have been registered to listen on those channels.

• Another implementation, using instant messages, would be useful for the added privacy, however time lag between messages are significant and it would be desirable not to have these messages show up on the client itself so a flag would need to be added for plugin-only instant messages.

• Other ideas, such as HTTP requests or Emails, for external plugin communication should be discarded quickly for the very reason that most systems now have significant firewalls and NAT'd connections which will deny such communication channels immediately.