Talk:LLSD

This is a talk page associated with the Open Source Portal. Changes to all pages like this one can be tracked by watching the "Related Changes" for "Category:Open Source Talk Page"
Please sign comments you leave here by putting four tildes (~~~~) at the end of your comment. For more guidelines, see Talk Page Guidelines

LLSD JSON-ish notation

The login sequence appears to use "binary" LLSD for two of the variables, home and look_at. Unfortunately the format doesn't match up exactly with what is documented on this wiki. Sample values:

{'region_handle':[r255232, r256512], 'position':[r33.6, r33.71, r43.13], 'look_at':[r34.6, r33.71, r43.13]}

[r0.99967899999999998428,r-0.025334599999999998787,r0]

No size values, and the map keys are encased in single quotes. Is this normal? -- —The preceding unsigned comment was added by Eddy Stryker

Oh wow, notation format. Ummmmm, I never documented that, did I. LLSD started it's life as a json-like language, with a well defined serialization which is not actually documented. I'll get on that. Phoenix Linden 16:10, 6 April 2007 (PDT)

Documentation has been added. Phoenix Linden 17:34, 12 April 2007 (PDT)

Versioning?

Personally I miss a few things here, especially the versioning/compatibility. Sure you can asume that older request just have less keys in a map, and that might work well for things like statistics results. But as soon as you want to call a method, it is much better to make the version obvious. You can encode that in a key/value pair, but it is much better to have that in a fixed element for routing (you can route requests for inventories to different servers, depending on the interface version)

I see a Version:i1 in the notation example for the teleport, which makes it clear, that this element is used already in LL. Maybe it is hard for you to make it to a llsd envelop, but I think you guys will have great use for it.

<llsd>
  <method version="1" interface="simstatistics" message="result" />
...

or something like that.--Bernd Elswit 10:27, 18 May 2007 (PDT)

Efficient binary support

maybe a more efficient binary transport can be added, too? For example Adobe's ASCII85 allows better compression (however you need to escape less-than and ampersand and CDATA). Very efficient could be precalculated huffman tables for the most common file formats.

Sample code at the end of the page: http://www.javaworld.com/javaworld/javatips/jw-javatip117.html

--Bernd Elswit 10:26, 18 May 2007 (PDT)

Any time that we need to conserve space or cpu resources, we will use zlib routines or binary serialization. Phoenix Linden 12:41, 21 May 2007 (PDT)

hexadecimal ?

does the integer type allow hexadecimal values ? e.g. 0xffcc00 instead of entering 16763904 ?

SignpostMarv Martin 09:54, 31 May 2007 (PDT)

Binary map and array encoding ?

The description is not clear how the delimiters for map and array elements should be encoded. See here:

array      '[' + htonl(array.length()) + ''(''child0'','' child1'','' ...'')'' + ']'

map        '{' + htonl(map.length()) + ''((''key0'',''value0''),(''key1, value1''),'' ...'')'' + '}'

Especially the binary encoding of the

''

marked values is not defined. As I am sitting at an implementation of this, I will try with the supposed reference implementation llsd.py and see what that actually does for this part.

--Leffard Lassard 10:04, 27 March 2008 (PDT)

From my own research it is more like this:

array      '[' + htonl(array.length()) + child0 + child1 + ']'

map        '{' + htonl(map.length()) + 'k' + htonl(key0.length) + key0 + value0 + 'k' + htonl(key1.length) + key1 + value 1 ... + '}'

--Leffard Lassard 11:26, 28 March 2008 (PDT)

XML <-> Notation?

The XML format is, let's face it, not fun to read or write, for humans, in those weird cases where humans have to. Is there a serialization converter, somewhere, or should I just rig my own? --Ky Aska 06:12, 3 June 2008 (PDT)

Motivations Behind LLSD

Just a quick note to say i've been having discussions with peeps about why LLSD was invented in the first place; more discussions than I ever thought I would have on the subject. The best answer I could give was a) we like dynamic data models and b) it helps a bit to avoid the Fragile Binary Interface problem. If we ever get around to updating the intro, we may want to mention why dynamic data models are "nice" from an agile programming perspective and why FBI is bad. And BTW, here's the wikipedia entry on FBI: http://en.wikipedia.org/wiki/Fragile_binary_interface_problem . --Infinity Linden

base85 considered harmful

Please note: base85 as an encoding for binary elements in the XML serialization of LLSD data is not canonical.