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)

Map-keys in the reference implementation at reference implementation seem to not support full UTF8 Strings. They seem to support only ASCII characters, which seems to be a python dictionary type problem.

--Leffard Lassard 06:26, 3 April 2008 (PDT)