Re: [mmox] The Story So Far...

Jon Watte <jwatte@gmail.com> Thu, 19 February 2009 05:53 UTC

Return-Path: <jwatte@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 008253A68EC for <mmox@core3.amsl.com>; Wed, 18 Feb 2009 21:53:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_44=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 di5fn9EhYE-H for <mmox@core3.amsl.com>; Wed, 18 Feb 2009 21:53:48 -0800 (PST)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id E0EE13A682D for <mmox@ietf.org>; Wed, 18 Feb 2009 21:53:47 -0800 (PST)
Received: by rv-out-0506.google.com with SMTP id l9so248495rvb.49 for <mmox@ietf.org>; Wed, 18 Feb 2009 21:54:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=pFxA6WE9bDc9OaBXt6hV6e+YydDISakd+lf6kmuPmF4=; b=h0SgAA7GaWUlj1LQpihEAf0cgOXa73PMl2koPl52tmvakN3q2evQs/5Ud0rMvUchil tiyIjKIqjD3t85HePRhtIDm4mykBRFiydbJ3miPJaboCTJvN95EZ9f4dHnwSOhEpWYVC +tTwzD2NYRJPDESsnV2BGUxNvgdHf5Mq5ZmB8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=pZ4E8l3K4brEpJvAYtOTzsSx8Y5vXVkVXIOSqy1Z48c4FYL1bKSqI8t5//Nuw6/KGw 2INYhPKnuqdk/tY9SV5gygCYXnKbZvZo1T2wIYh8TT1FMptY2t/0+kag+JXI628kuSfG l0Cyzf8Lnbkt4C0N4NqOcMsZXFS+te11RC/jo=
Received: by 10.141.4.20 with SMTP id g20mr3625874rvi.173.1235022841060; Wed, 18 Feb 2009 21:54:01 -0800 (PST)
Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id f42sm901493rvb.3.2009.02.18.21.54.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 21:54:00 -0800 (PST)
Message-ID: <499CF3F7.1010304@gmail.com>
Date: Wed, 18 Feb 2009 21:53:59 -0800
From: Jon Watte <jwatte@gmail.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: "Hurliman, John" <john.hurliman@intel.com>
References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <62BFE5680C037E4DA0B0A08946C0933D501FE4C3@rrsmsx506.amr.corp.intel.com>
In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D501FE4C3@rrsmsx506.amr.corp.intel.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "mmox@ietf.org" <mmox@ietf.org>
Subject: Re: [mmox] The Story So Far...
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, 19 Feb 2009 05:53:49 -0000

Hurliman, John wrote:
> include anything like that. Instead, a teleport is done from grid A to grid B where identity and appearance are the only things that need to persist. I don't see why grid<->grid communication is fundamentally necessary to transfer identity and appearance.
>   

At least three reasons:

1) When I am logged into a virtual world, it's usually for a reason. For 
me, it's work -- my virtual world allows me to cooperate with remote 
workers, visualize 3D data, and have meetings that are more effective 
and cheaper than conference calls. (Customers love "cheaper" :-) If I 
were to log off my "home" virtual world, then I would lose some or all 
of those capabilities while I "went elsewhere." For example, if my 
company has a policy of recording all interactions in the world, for 
regulatory compliance, if I suddenly disconnected and connected to 
another grid, that function would not be present.

2) Object behavior is not portable. One system may use SecondLife Script 
version 2.3 for its objects. Another may use Java Runtime 1.5.6. A third 
may use Visual C++ 9.0 linkable libraries.

3) If you "grid hop" to another location, you have to have a client that 
can connect to whatever server protocol that location is using. Writing 
a "universal client" has proven to be quite quixotic for two reasons: a) 
Any real system will have to have a "home protocol" anyway to provide 
functionality not provided for in the standard, and b) re-implementing 
virtual world presence for a client as a separate channel only to use 
for interoperability isn't a good idea.


If I "grid hop," I might as well just have two clients installed (one 
that uses ClosedGardenWorld protocol 1.3, and one which uses 
WalledSpacesWorld protocol 2.7), and launch the right client for where I 
want to go -- the "benefit" of interoperability would be quite marginal; 
basically just not having to fill out a registration form for each 
world. No business will do a lot of engineering work to enable a 
scenario like that, because it delivers very little added value.

Sincerely,

jw