Re: [mmox] Learning from the past; focusing on the future

Jon Watte <jwatte@gmail.com> Mon, 23 February 2009 07:28 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 CCB2B3A681D for <mmox@core3.amsl.com>; Sun, 22 Feb 2009 23:28:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.563
X-Spam-Level:
X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599]
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 fd-M4WCo7sya for <mmox@core3.amsl.com>; Sun, 22 Feb 2009 23:28:01 -0800 (PST)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 009C53A67A1 for <mmox@ietf.org>; Sun, 22 Feb 2009 23:28:00 -0800 (PST)
Received: by rv-out-0506.google.com with SMTP id l9so1715184rvb.49 for <mmox@ietf.org>; Sun, 22 Feb 2009 23:28:17 -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=Xwpkh/fCVfHPBPVsr2nEPVUlKH39s8ePSKVOKRbxQoo=; b=d7I5ocHLCPnK9co3OoBCXy4F33/Nel1nve2IExGkqjX6EJ56Azs34Cn8dDQbEd9LVg MvaByaLW699zCLId6c8/vN41eUG++eF3bEGnbOHlk9lVSfxc5DPURR8Uis3kgRuwgBqR pOrPm8v3lnEq3BNqHYir1U7vvesfUwJ2l+OeU=
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=DliZu8TXObK65rEdFdwzE730DRZPLXQGaqn84FoQ2DebqFHPbG9eP3xEfbnJV3RAm4 JlQ52PXpXcYKYJiy+0iYFySM0hob/JosRnUgCwGf3r1++h5Ih0rgUdsB9CTdALhPHyTQ lsEgGfPlStkQvXMmjXmPJUXgy2cdxqt+PgXxg=
Received: by 10.141.122.20 with SMTP id z20mr1894259rvm.171.1235374097476; Sun, 22 Feb 2009 23:28:17 -0800 (PST)
Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id c20sm6116216rvf.1.2009.02.22.23.28.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 23:28:17 -0800 (PST)
Message-ID: <49A2500F.3000104@gmail.com>
Date: Sun, 22 Feb 2009 23:28:15 -0800
From: Jon Watte <jwatte@gmail.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Mystical Demina <MysticalDemina@xrgrid.com>
References: <FDF00DC7F277439581F4909E2C549AA6@KEVINPC>
In-Reply-To: <FDF00DC7F277439581F4909E2C549AA6@KEVINPC>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: mmox@ietf.org
Subject: Re: [mmox] Learning from the past; focusing on the future
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: Mon, 23 Feb 2009 07:28:01 -0000

Mystical Demina wrote:
>
> I think until we define things in these terms the actual physical 
> protocols don’t do us much good.
>

There have actually been a lot of those proposals on the list already. 
The reason we're talking about meshes vs prims is to make the point that 
/only/ specifying the mechanism is not sufficient to actually achieve 
interoperability; specifying a reliable minimum capability for each 
mechanism ("if you support the mechanism, you support at least this 
format") is necessary for actual interoperability. Meshes just turned 
out to be one of the illustrative examples of why this is so.

I think the /first/ thing we need to decide is whether we're building:

1) A protocol that lets some number of second-life derived client 
softwares cross-connect to some number of second-life derived services, 
possibly bringing along some number of second-life derived assets (I've 
heard proposals that boil down to this from a few people)

or

2) A protocol that lets significantly different virutal world systems 
interoperate to share in creating a single, bigger, more diverse 
simulation (Some other people, including me, are presenting proposals 
along these lines).

However, right now, I don't even think we know how to make that 
decision. We need to make this decision, so that the people who aren't 
interested in "the other" approach can properly decide where and how to 
spend time and resources.

Sincerely,

jw


Sincerely,

jw