Talk:OGP LLSD

Please add an unsigned 32-bit integer type to LLSD. LLSD XML human readability is shot when it comes to uints, and a lot of time is spent doing the Base64 encoding/decoding. See MU-18. --Eddy Stryker 17:53, 30 September 2008 (PDT)

---

Eddy...

1. how much is "a lot of time" ?
2. what is the alternative binary encoding that you're recommending?
3. wrt integer encoding.. can't you just assume two's complement and convert negative values to positive ones?

-- Infinity Linden 19:22, 30 September 2008 (PDT)

---

Hmm.. okay... how's this for an idea...

LLSD is really supposed to be an abstract syntax *yeah... i know... why are we defining int's as being signed and 32 bits wide in an abstract syntax* but the XML serialization really is an XML serialization, not the definition of LLSD. Maybe we could specify that concrete implementations of integers MUST support 32 bits of 2s complement integer (as most all modern systems do). We could then add ( signed, unsigned and IPV4) as encodings of the int element of the XML serialization, the same way that we are thinking of supporting base64 and base16 encodings of binary elements. so... where you would have something like this now:

<llsd>
  <map>
    <key>ipAddress</key>
    <binary encoding="base16">1501A8C0</binary>
    <key>unsignedInteger</key>
    <binary encoding="base64">/////w==</binary>
    <key>signedInteger</key>
    <int>-1</int>
  </map>
</llsd>

we would have something like this:

<llsd>
  <map>
    <key>ipAddress</key>
    <int encoding="ipv4">192.168.1.21</int>
    <key>unsignedInteger</key>
    <int encoding="unsigned">4294967295</int>
    <key>signedInteger</key>
    <int>-1</int>
  </map>
</llsd>

it is, however, vaguely problematic in that we would have to add annotation to LLIDL to define the preferred encoding of each element.. though we might be able to simply say that this is a detail for implementations, not the definition of LLIDL. -- Infinity Linden 15:12, 1 October 2008 (PDT)