[sldev] Prim metadata formats was Re: LSL initiated Prim metadata...
secret.argent at gmail.com
Wed Feb 28 06:31:48 PST 2007
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
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
> "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:
Where attribute is a list of type-value pairs, describing the
serialized format for the attribute, eg:
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.
More information about the SLDev