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

Gareth Nelson <gareth@litesim.com> Tue, 24 February 2009 07:20 UTC

Return-Path: <gareth@litesim.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 E86563A68FE for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 23:20:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.842
X-Spam-Level:
X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 bEkEvEunG-dN for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 23:20:11 -0800 (PST)
Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.153]) by core3.amsl.com (Postfix) with ESMTP id 292D93A67D1 for <mmox@ietf.org>; Mon, 23 Feb 2009 23:20:11 -0800 (PST)
Received: by po-out-1718.google.com with SMTP id b23so7519241poe.4 for <mmox@ietf.org>; Mon, 23 Feb 2009 23:20:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.141.193.9 with SMTP id v9mr2441437rvp.120.1235460028711; Mon, 23 Feb 2009 23:20:28 -0800 (PST)
In-Reply-To: <49A311BC.90405@gmail.com>
References: <FDF00DC7F277439581F4909E2C549AA6@KEVINPC> <49A2500F.3000104@gmail.com> <e0b04bba0902230031s5065080j61058011201cd929@mail.gmail.com> <49A311BC.90405@gmail.com>
Date: Tue, 24 Feb 2009 07:20:28 +0000
Message-ID: <61dbdd7d0902232320k5451db6av27dadc81424ca7c2@mail.gmail.com>
From: Gareth Nelson <gareth@litesim.com>
To: Jon Watte <jwatte@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Mystical Demina <MysticalDemina@xrgrid.com>, 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: Tue, 24 Feb 2009 07:20:12 -0000

I have a nice solution to this one, take OGP and build on it :)
Add the following:
1 bowl of transport mediums
1 cup of object position update messages
1 cup of geometrical definitions
Mix 2 cups until a clean set of messages is defined
Skim away SL limits, mix in and retain the basics (i.e web services,
agent/region domains split, HTTP capabilities over https:// URLs)
Bake for 50 minutes at 1337c and serve with a side portion of win

On Mon, Feb 23, 2009 at 9:14 PM, Jon Watte <jwatte@gmail.com> wrote:
> Morgaine wrote:
>>
>> I can't understand why you continue to raise the spectre that we're here
>> to rubberstamp SL standards.  We aren't.  I'm not aware of anybody with that
>> agenda.
>>
>
> Because there are several people on this list who say "OpenSim and Second
> Life are already trying to do client interoperability; I think we should run
> with it and not worry about something bigger."
> Similarly, I find that the current OGP proposal specifies some thing
> ("Rezzing" of avatars) that are Second Life centric, while not specifying
> other things that would be necessary for an actually useful interoperable
> virtual world (like entity telemetry).
>
> Similarly, if OGP is specified as a mostly empty vessel that can contain
> arbitrary negotiated data, what would probably happen would be that OpenSim
> puts OpenSim data in that vessel, and IMVU puts IMVU data in that vessel,
> and both claim to support "OGP interoperability" but you can't do anything
> useful through that claim. I want to avoid that outcome.
>>
>> We are working in good faith towards your item 2), while noting that item
>> 2) means interop with "all" reasonable worlds, and that includes Linden
>> worlds.  It's not either/or, it's both.  Please grant us that, so that we
>> can actually make headway.
>>
>> /(Proviso: your item 2) says /*single ... simulation*/, which is
>> incorrect, as we have no remit to straightjacket diverse worlds into a
>> single simulation.)/
>
> What I mean by "single simulation" is what the user sees when connected to a
> specific, interoperating instance. I suppose the user could be connected to
> multiple of those, similar to opening multiple video streams in a media
> player, but then those generally have "nothing" to do with each other.
>
>
> Okay, so if most of us agree on 2), can we just say we have "rough
> consensus" on that, and politely reject any attempt to steer the work
> towards 1)?
>
>
> Sincerely,
>
> jw
>
>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
>