[mmox] Jeeps and jungle roads

Catherine Pfeffer <cathypfeffer@gmail.com> Thu, 26 February 2009 12:41 UTC

Return-Path: <cathypfeffer@gmail.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 CE3FB3A6BAA for <mmox@core3.amsl.com>; Thu, 26 Feb 2009 04:41:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.359
X-Spam-Level:
X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 VD2NpPOqmkfz for <mmox@core3.amsl.com>; Thu, 26 Feb 2009 04:41:50 -0800 (PST)
Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 0616D3A6AAA for <mmox@ietf.org>; Thu, 26 Feb 2009 04:41:49 -0800 (PST)
Received: by bwz26 with SMTP id 26so480217bwz.37 for <mmox@ietf.org>; Thu, 26 Feb 2009 04:42:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=1lOYHWzM99R9WWw5F0oKVZRk1KXm/VaAY8x4LkOztCE=; b=hDNHGqYHuV+50ocI7nV0w+vutH0phN01rLShq+i+exZIvJeNKV8Vl1SvAJUq25DJPP N2kQABt0RBcvdjQbGMJQwyPSkqdIhyc90xttcTA7RMuNMVTeWWmn46Dsdpjk/gomTisj 49dMzPBPu+SL2iZ0KbWFjgw3B267SDRQFX8As=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=TPZdZxjZ96H+cO+1LO2OM3Nuyf5Sq4TpEVUdDToRZbvrBNw8KJuLKABBIP+K7/5GEM v7tqV62MKYTYUHN5tkYH1gLUyAP+tOObKBXA9nBcKqXgueCXkQx1XUTW2O8f4s7eBb8H uzhSpbDO1ZT37GQIX9g5oTW1n+1eq+Zw3uLXk=
MIME-Version: 1.0
Received: by 10.181.48.13 with SMTP id a13mr446207bkk.43.1235652130369; Thu, 26 Feb 2009 04:42:10 -0800 (PST)
Date: Thu, 26 Feb 2009 13:42:10 +0100
Message-ID: <ebe4d1860902260442u71e25541k7846558c1b8bc966@mail.gmail.com>
From: Catherine Pfeffer <cathypfeffer@gmail.com>
To: mmox@ietf.org
Content-Type: multipart/alternative; boundary="001485f91c304beff80463d1ae14"
Subject: [mmox] Jeeps and jungle roads
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: Thu, 26 Feb 2009 12:41:51 -0000

Lisa wrote:
> In a *standard*?  Cathy does not.  She flags an error.  The standard
> that would have produced the interoperability so far in your example
> would have said "bar is an integer".
>
> In fact, if there's agreed interoperability between Cathy, Meadhbh and
> David on the foo, bar and baz semantics, then none of them need to be
> annotated with their datatypes.

Yeah. That's strange, isn't it? ;-) But remind the Lindens are pioneers, and
pioneers don't always think in the conventional way ;-).

I'd like to take Infinity's defense on this one.

A standard is about agreeing. But a standard also needs to evolve. It needs
to address the case where some people haven't / don't want to implement 100%
of it. A standard needs to acknowledge the fact that everyone has not the
same user base and the same use cases. In the VW case there is the
additional requirement that, even inside of a single grid, the protocol
won't be the same on each simulator, and end users will also use viewers
that handle different versions of the protocol. Also, Virtual Worlds are
very young and the technology evolves at an incredible rate. That's a mess
(sorry for the word) that even HTML, another client-server protocol that has
evolved a lot over time, never had to face at the same scale.

I think that's why Lindens have designed something (binary LLSD) that beats
in flexibility even what modern XML does, while remaining very simple
(sometimes oversimplified, if we consider that all scalars are signed 32
bits). There is a price to pay for this flexibility and simplicity, for
example they need to send the data types together with the data, and they
have to define a whole range of on-the-fly conversions, but this price is
minor when compared to the benefits.

> try:
>     barval = int(xmldoc.getElementsByTagName('bar').data)
> except ValueError:
>     return new ErrorResponse(400, "Bad Request")

I think that's precisely what the Lindens want to avoid. They never want to
reject data, they rather attempt to do their best with unexpected data,
because the user experience must continue, even in a degraded mode, and
never have the viewer display "400 Bad Request".

If protocols were cars, then LLSD would be a jeep. Jeeps don't stop when the
road is not perfectly flat and unencumbered.

-- 
Cathy