Re: [mmox] Formalizing my proposal

Lisa Dusseault <> Tue, 24 February 2009 21:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C7C0E28C120 for <>; Tue, 24 Feb 2009 13:51:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.404
X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uqr+rqlsdePL for <>; Tue, 24 Feb 2009 13:51:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9D1CE28C115 for <>; Tue, 24 Feb 2009 13:51:42 -0800 (PST)
Received: by with SMTP id l9so2485960rvb.49 for <>; Tue, 24 Feb 2009 13:52:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=kvcbgcHnnCm18SgfZN+ucy+F1Sy59kcGW9U59ltO/SE=; b=AJW8udMVxK9c2VoYBvuE/rqXR6vChW/hJ26oF//54/jeXNxctrwWKrVFxLF2U6G1As YieFGA5CEefVwYWIsRYYU3lcMuptmDPMcYLBJzOitNTWmxlDI00d7nsAYsu1pBzd/Ugl pQjmkZpxzPbmx5NTtyluU/Gei9fqTa8GNkZFI=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gaYp+8NQbyCdA64l225y5m7PkMvxo55QVStLxdo4QvlO2/p5RQQA5Ib2MOOiJOPNh9 Xm726xDhu7OTV2Vp6j/VPEBToVqO7d8ulySPNWqDux1o9Pgp4VDgwgiAnzJukwqEE1EB p7eudzsKHONNdnFRbcfTo0CbZfUu6ZjD/tJjM=
MIME-Version: 1.0
Received: by with SMTP id y4mr2792803rvn.88.1235512321351; Tue, 24 Feb 2009 13:52:01 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Tue, 24 Feb 2009 13:52:01 -0800
Message-ID: <>
From: Lisa Dusseault <>
To: Catherine Pfeffer <>
Content-Type: multipart/alternative; boundary="000e0cd1461407a0f20463b121a7"
Subject: Re: [mmox] Formalizing my proposal
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Feb 2009 21:51:43 -0000

I completely agree with this.  We'd need a pretty good reason to standardize
three serializations of the same data up front.  We'd also need a careful
model for who needs to support all, and who can choose which to support, and
how negotiation is done.  It's all a *lot* more standards work and
multiplies risks of interop failures.

That said, there is certainly good engineering behind having the layering
abstractions, and in some cases multiple serializations are worthwhile.
After 10 years of being in its own format, there's some effort to do an XML
version of iCalendar for inviting people to meetings.  The problem is no
negotiation support in the tools that use iCalendar.


On Tue, Feb 24, 2009 at 11:04 AM, Catherine Pfeffer

> Infinity wrote:
> > 1. can you please submit your proposal?
> Sure. I'll submit a proposal that makes the XML serialization better,
> although it would assume:
> 1)- that LLSD is what we need for lower layer
> 2) that we would stick to three serializations for LLSD and not just one,
> leading to clumsy XML
> both points are still not certainties in my mind. But I'll send the
> formalized proposal as you asked it.
> > most of the XML LLSD is sent over HTTPS,
> > which might explain why you can't see it in wireshark
> Aaah, Ok, thanks for the tip! ;-)
> > 6. the reason we separate the serialization from the protocol
> > definition is we want to avoid having to add "binary serialization",
> > "json serialization" and "xml serialization" sections to each defined
> > protocol interaction.
> Yes, and that leads to a XML serialization that does not take all the
> advantage of what can be done in XML, and that takes a lot of bandwidth.
> Again, why would we need three serializations when one is just enough? Not
> saying that it's just 1/3rd of the implementation effort...
> > I think there's a history of people defining protocols
> > using relatively "high level" abstractions, then providing mechanistic
> > technique for generating the "octets over the wire."
> That's correct, it's nice to think in abstract terms, and then map the
> result to a given implementation. That does not mean you need three
> implementations...
> > 7. i really like the idea of using LLSD to represent meshes, link-sets
> > of prims, or even 2d SVG representations of avatars and objects.
> ... which means, in XML, that we could not re-use existing meshes or SVG
> XML dialects just by changing the namespace, but that we would have to
> "convert" everything to LLSD.
> While this would certainly work, it sounds to me like a lot of efforts,
> while simply mixing
>         vw:
> and
>         svg:
> namespaces in one single file could do the trick. Otherwise, you'd first
> have to define how SVG remaps to LLSD, then implement it.
> XML namespaces are precisely offering this ability to mix different type of
> data from different standards without ambiguity and without any need to
> remap one standard into the other.
> --
> Cathy
> _______________________________________________
> mmox mailing list