Plugin LSL Communication

From Second Life Wiki
Revision as of 19:59, 24 February 2007 by Iron Perth (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Hack

While there's no official solution, here's what I came up with for now:

Client to LSL: speaks on a channel directly. Nothing special here. LSL to Client: llOwnerSay, with this format:

$VwrComm$VERSION$COMPONENT$DATA
  • VwrComm: Header, must be present
  • VERSION: Protocol version
  • COMPONENT: Component inside the viewer the message is for
  • DATA: Data being sent

Example

$VwrComm$0$AvatarScanner$LoginComplete

Implementation

Code for this can be found at [1], line 2047

Escaping the llOwnerSay chat messages with a "|" instead of a "$" may be desireable if we only check the first character to see if it is a plugin only message.

Discussion: 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 discussion 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.