[sldev] Prim metadata formats was Re: LSL initiated Prim metadata...

[Argent Stonecutter]

On Feb 27, 2007, at 7:13 PM, Jason Giglio wrote:
> In case you weren't paying attention (and it appears you weren't),

I wasn't responding to your proposal here, I was responding to  
Jacek's proposal.

However, I do think you're missing one point to my suggestion of  
using a list, and that is that both ends of the system need  
structured data.

> "the script" doesn't encode the data under my proposal, except  
> during development.  After development is complete the new built-in  
> LL-provided LSL functions might indeed take a list, which it will  
> then convert into the proper string.

In other words you're serializing the data as a string. Linden Labs  
already has a mechanism for serializing prim attributes for storage  
and transmission to the client, and it's a strongly typed format  
that's bidirectionally convertible to an LSL list. The "new built-in  
LL-provided LSL functions" should convert the prim parameters into  
that format, not a string, and the client-side code should accept  
that format. To really use this to prototype code that's going to be  
used unchanged by Linden Labs, the call should either be:

llSetExperimentalAttribute(list attribute);

Where attribute is a list of type-value pairs, describing the  
serialized format for the attribute, eg:  
[ATTR_U8,taste,ATTR_F32,angle,ATTR_F32,wobble].

Or:

llSetExperimentalAttribute(string format, list attribute);

Where format is a string like "U8,F32,F32" that describes the format  
of the attribute.

That way when the capability goes into production the prim data will  
be in the right format, and the client code will already be seeing  
and interpreting the data in Linden Labs' preferred format.

Note that I am not re-introducing an identifier here. This message is  
not about Jacek's proposal, and to avoid further crossed wires I'll  
change the subject line.