Re: [mmox] Creating walled gardens considered harmful

Larry Masinter <masinter@adobe.com> Tue, 31 March 2009 02:32 UTC

Return-Path: <masinter@adobe.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 DEB9C3A6B68 for <mmox@core3.amsl.com>; Mon, 30 Mar 2009 19:32:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.349
X-Spam-Level:
X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 k7Ut9NOXErGu for <mmox@core3.amsl.com>; Mon, 30 Mar 2009 19:32:14 -0700 (PDT)
Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by core3.amsl.com (Postfix) with ESMTP id 92D703A6930 for <mmox@ietf.org>; Mon, 30 Mar 2009 19:32:13 -0700 (PDT)
Received: from source ([192.150.8.22]) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKSdGA5uRPr+PR+KxLqqT4VS3UdfAJFUzU@postini.com; Mon, 30 Mar 2009 19:33:13 PDT
Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n2V2X7E0002083; Mon, 30 Mar 2009 19:33:08 -0700 (PDT)
Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n2V2X6iq015437; Mon, 30 Mar 2009 19:33:06 -0700 (PDT)
Received: from nambx04.corp.adobe.com ([10.8.127.98]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Mon, 30 Mar 2009 19:33:06 -0700
From: Larry Masinter <masinter@adobe.com>
To: Jon Watte <jwatte@gmail.com>, James Stallings II <james.stallings@gmail.com>
Date: Mon, 30 Mar 2009 19:33:01 -0700
Thread-Topic: [mmox] Creating walled gardens considered harmful
Thread-Index: AcmxgpphRxsIZk5fSfa0zTFdUI+2MQAIktIA
Message-ID: <8B62A039C620904E92F1233570534C9B0118CD4EE5ED@nambx04.corp.adobe.com>
References: <e0b04bba0903250007k6886383bja0a06884e8081ac7@mail.gmail.com> <49CDC0BA.5070403@gmail.com> <f0b9e3410903280920o1e436337hb4c40a5b5f124876@mail.gmail.com> <49CE5BDC.5040808@gmail.com> <e0b04bba0903281057g943ce9cjdcce0fc2712a4ec3@mail.gmail.com> <49CF1B1E.4070506@gmail.com> <e0b04bba0903290138ifbfaf18p930f87d1e49e6dbb@mail.gmail.com> <49D0081E.4010007@gmail.com> <e0b04bba0903291942k69f6e970yee8b8a80dd8df2fa@mail.gmail.com> <49D0D846.5010401@gmail.com> <170fa1780903300854s34da03eaq8b3ed2f7eb9c2a62@mail.gmail.com> <49D1401E.5000905@gmail.com>
In-Reply-To: <49D1401E.5000905@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: MMOX-IETF <mmox@ietf.org>
Subject: Re: [mmox] Creating walled gardens considered harmful
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: Tue, 31 Mar 2009 02:32:15 -0000

> http://tools.ietf.org/html/draft-jwatte-mmox-use-cases-00

"  The point is
   that interoperability does not require the source and the destination
   to be from the same technology family, use the same simulation
   technology, or even that the clients must understand protocols other
   than those native to the respective simulation system."

I don't understand how most of those use cases can be managed if
the source & destination have different simulation models, skeleton
structions, scripting languages, physics models, rendering engines,
etc.

>   The benefit is that users of different virtual worlds can invite and
>  communicate with each other using the virtual world metaphore,
>   regardless of the particular virtual world technology used for their
>   "home base" virtual world.

I think this is "if you can do A, then you can do A". Why would anyone
 want to do that, and how would it help them?

In section 2.2.1, the integration of a "plant" and a "city" requires
so many seams to be knit, I wonder how feasible it really is. Even
between virtual worlds with the same underlying infrastructure, welding
a "building" into a city requires a lot of work aligning, wouldn't it?

Just wondering how practical these use cases are.

Larry
--
http://larry.masinter.net