Extensible Prim Attributes from LSL

The Chicken and the Egg

There are many new features that can be implemented almost exclusively on the client side, but the main intention would be their use from LSL. The OpenSL project has little ability to work on these features without the corresponding LSL-side changes, and LL might be loathe to write in LSL side changes until the client side abilities are in place. This creates a classic chicken and egg problem.

Some examples of this are:

• Programmatic Textures
• Web Textures
• Plugin architecture

The Solution

A generic LSL function set to allow prim-specific communications to the client. This would allow tagging prims with arbitrary communications that the client can pick up and use for whatever purpose.

llSetMetaInformation(string payload);  //sets metainformation for tag 0 for this prim.

This would be on a per-prim level, similar to llSetObjectDesc, except hidden to the user. The limit should be at least 1024 bytes. The payload need not persist when the asset is saved to inventory, but it would be nice if it did.

This MetaInformation would be tagged with a numeric identifier, always 0 for llSetMetaInformation. When the feature is accepted and new, feature specific LSL functions are added, this numeric identifier can simply be changed, requiring very little code change.

Examples

Web Textures

llSetMetaInformation("webtexture, face1, http://www.myhost.com/webtexture.php?text=my%20text");  //inserts string into tag 0 for this prim.

This way web textures could be implmented on the client. When LL decides to officially support web textures, they will assign it a new tag number (lets say 2) and add:

llSetWebTexture(string url, integer face);  //Updates tag 2 with "webtexture, face<facenum>, <url>"

Which will simply be equivalent to a llSetMetaInformation on tag 2, using the same format that the feature used before, but now packaged in a nice "consumer friendly" format.

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