Subject: [mmox] Example of what could be a real XML LLSD

From: Catherine Pfeffer <[email-masked]>
Date: Wed, 25 Feb 2009 02:24:40 +0100

Hello,

Here is a real LLSD packet. Below I'll show how it could look like if we
would abandon the 1:1 mapping to binary serialization.

If transposing 1:1 the binary encoding, the packet is 2688 bytes long. If
doing it in a more xml-ish way, the packet is 1065 bytes long. That's 40 %
of the length the current LLSD proposal generates. It's also more legible by
humans, easier to validate and easier to parse. Those figures include 2
spaces of indentation at each tag level, and all the newline characters.

First the "transposition of binary serialization" way:

<llsd>
  <map>
    <key>AgentData</key>
    <map>
      <key>AgentId</key>
      <uuid>81466fc7-276f-455d-9b72-8316e9712535</uuid>
      <key>GroupId</key>
      <uuid/>
      <key>SessionId</key>
      <uuid>4bbb6fa9-e649-4507-a709-8831c237c4ee</uuid>
    </map>
    <key>ObjectData</key>
    <map>
      <key>BypassRaycast</key>
      <boolean>1</boolean>
      <key>EveryoneMask</key>
      <binary encoding="base64">AAAAAA==</binary>
      <key>Flags</key>
      <binary encoding="base64">AAAAAg==</binary>
      <key>GroupMask</key>
      <binary encoding="base64">AAAAAA==</binary>
      <key>Material</key>
      <integer>3</integer>
      <key>NextOwnerMask</key>
      <binary encoding="base64">AAjAAA==</binary>
      <key>PCode</key>
      <integer>9</integer>
      <key>Path</key>
      <map>
        <key>Begin</key>
        <integer>0</integer>
        <key>Curve</key>
        <integer>16</integer>
        <key>End</key>
        <integer>0</integer>
        <key>RadiusOffset</key>
        <integer>0</integer>
        <key>Revolutions</key>
        <integer>0</integer>
        <key>ScaleX</key>
        <integer>100</integer>
        <key>ScaleY</key>
        <integer>100</integer>
        <key>ShearX</key>
        <integer>0</integer>
        <key>ShearY</key>
        <integer>0</integer>
        <key>Skew</key>
        <integer>0</integer>
        <key>TaperX</key>
        <integer>0</integer>
        <key>TaperY</key>
        <integer>0</integer>
        <key>Twist</key>
        <integer>0</integer>
        <key>TwistBegin</key>
        <integer>0</integer>
      </map>
      <key>Profile</key>
      <map>
        <key>Begin</key>
        <integer>0</integer>
        <key>Curve</key>
        <integer>1</integer>
        <key>End</key>
        <integer>0</integer>
        <key>Hollow</key>
        <integer>0</integer>
      </map>
      <key>RayEnd</key>
      <array>
        <real>42.9329986572265625</real>
        <real>29.6600322723388671875</real>
        <real>31.399318695068359375</real>
      </array>
      <key>RayEndIsIntersection</key>
      <boolean>0</boolean>
      <key>RayStart</key>
      <array>
        <real>48.281482696533203125</real>
        <real>32.063152313232421875</real>
        <real>34.092010498046875</real>
      </array>
      <key>RayTargetId</key>
      <uuid/>
      <key>Rotation</key>
      <array>
        <real>0</real>
        <real>0</real>
        <real>0</real>
        <real>1</real>
      </array>
      <key>Scale</key>
      <array>
        <real>0.5</real>
        <real>0.5</real>
        <real>0.5</real>
      </array>
      <key>State</key>
      <integer>0</integer>
    </map>
  </map>
</llsd>

Now the "XML" way:

<llsd>
  <AgentData
      AgentId="81466fc7-276f-455d-9b72-8316e9712535"
      GroupId=""
      SessionId="4bbb6fa9-e649-4507-a709-8831c237c4ee" />
    <ObjectData
        BypassRaycast="1"
        EveryoneMask="0x00000000"
        Flags="0x00000002"
        GroupMask="0x00000000"
        Material="3"
        NextOwnerMask="0x0008C000"
        PCode="9">
      <Path
          Begin="0"
          Curve="16"
          End="0"
          RadiusOffset="0"
          Revolutions="0"
          ScaleX="100"
          ScaleY="100"
          ShearX="0"
          ShearY="0"
          Skew="0"
          TaperX="0"
          TaperY="0"
          Twist="0"
          TwistBegin="0" />
        <Profile
           Begin="0"
           Curve="1"
            End="0"
            Hollow="0" />
      <RayEnd
            x="42.9329986572265625"
            y="29.6600322723388671875"
            z="31.399318695068359375"
            IsIntersection="0" />
      <RayStart
            x="48.281482696533203125"
            y="32.063152313232421875"
            z="34.092010498046875" />
      <RayTargetId uuid="" />
      <Rotation x="0" y="0" z="0" s="1" />
      <Scale x="0.5" y="0.5" z="0.5" />
      <State bool="0" />
    </ObjectData>
</llsd>

Even better results could be achieved by using default values for some
attributes.

-- 
Cathy

---

From: [email-masked]
Date: Tue, 24 Feb 2009 20:19:30 -0800 (PST)

Apologies if I missed the answer if it was in an earlier message...

The "XML way" message appears to be loosly typed. How could a parser create an object from that XML data and know the difference between an integer and a float, or a UUID and a string? 

--Tom

________________________________
From: Catherine Pfeffer <[email-masked]>
To: [email-masked]
Sent: Tuesday, February 24, 2009 5:24:40 PM
Subject: [mmox] Example of what could be a real XML LLSD

Hello,

Here is a real LLSD packet. Below I'll show how it could look like if we would abandon the 1:1 mapping to binary serialization.

If transposing 1:1 the binary encoding, the packet is 2688 bytes long. If doing it in a more xml-ish way, the packet is 1065 bytes long. That's 40 % of the length the current LLSD proposal generates. It's also more legible by humans, easier to validate and easier to parse. Those figures include 2 spaces of indentation at each tag level, and all the newline characters.

<llsd>
  <map>
    <key>AgentData</key>
    <map>
      <key>AgentId</key>

Now the "XML" way:

<llsd>
  <AgentData

Even better results could be achieved by using default values for some attributes.

-- 
Cathy

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Tue, 24 Feb 2009 22:27:33 -0800

again... getting back to the discussion of efficiency... if we were  
concerned about the size of XML messages being sent over HTTP, i would  
suspect the first thing we would do would be to use the "Content- 
Encoding: gzip" header. Without changing the data, this would result  
in a Content-Length of 635 octets for the first (traditional LLSD)  
message and a Content-Length of 547 octets for the second (XMLish  
PDU), a full 86% of the traditional LLSD. which, not surprisingly is  
about the same percentage if you remove whitespace from both messages  
and remove the superfluous encoding attributes to the binaries.

however... you can be a little more radical... if you preserve the  
LLSD processing expectations described in a previous  message and you  
remove the elements that are defaults, you wind up with a message that  
is 462 octets after compression. fwiw.. i did the same thing to the  
JSON encoding and came up with a 477 octet message.

so.. without resorting to radicality, the new PDU style saves you 14%  
but comes at the price of requiring you to write a specialized XML  
parser that understands how to take data out of the new PDU and into a  
data structure of some sort.

-cheers
-meadhbh

On Feb 24, 2009, at 5:24 PM, Catherine Pfeffer wrote:

> Hello,
>
> Here is a real LLSD packet. Below I'll show how it could look like  
> if we would abandon the 1:1 mapping to binary serialization.
>
> If transposing 1:1 the binary encoding, the packet is 2688 bytes  
> long. If doing it in a more xml-ish way, the packet is 1065 bytes  
> long. That's 40 % of the length the current LLSD proposal generates.  
> It's also more legible by humans, easier to validate and easier to  
> parse. Those figures include 2 spaces of indentation at each tag  
> level, and all the newline characters.
>
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox