Re: [mmox] Example of what could be a real XML LLSD
"Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com> Wed, 25 February 2009 06:27 UTC
Return-Path: <infinity@lindenlab.com>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC6CB3A6B51 for <mmox@core3.amsl.com>; Tue, 24 Feb 2009 22:27:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.482
X-Spam-Level:
X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b30x5qDdFNwo for <mmox@core3.amsl.com>; Tue, 24 Feb 2009 22:27:15 -0800 (PST)
Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 883A03A68A5 for <mmox@ietf.org>; Tue, 24 Feb 2009 22:27:15 -0800 (PST)
Received: from infinity.vpn.lindenlab.com (infinity.vpn.lindenlab.com [10.0.254.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id DE3CD3DBC44D; Tue, 24 Feb 2009 22:27:34 -0800 (PST)
Message-Id: <D87E1999-04DB-4F60-8B9D-FC65AEFCAC77@lindenlab.com>
From: "Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com>
To: Catherine Pfeffer <cathypfeffer@gmail.com>
In-Reply-To: <ebe4d1860902241724s537a2d4dv1fd5014b50b6e085@mail.gmail.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Tue, 24 Feb 2009 22:27:33 -0800
References: <ebe4d1860902241724s537a2d4dv1fd5014b50b6e085@mail.gmail.com>
X-Mailer: Apple Mail (2.930.3)
Cc: mmox@ietf.org
Subject: Re: [mmox] Example of what could be a real XML LLSD
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 06:27:16 -0000
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. > > 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 > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox
- [mmox] Example of what could be a real XML LLSD Catherine Pfeffer
- Re: [mmox] Example of what could be a real XML LL… eh2th-mmox
- Re: [mmox] Example of what could be a real XML LL… Meadhbh Hamrick (Infinity)