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

"Hurliman, John" <john.hurliman@intel.com> Wed, 18 February 2009 00:16 UTC

Return-Path: <john.hurliman@intel.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 DF7E83A69FE for <mmox@core3.amsl.com>; Tue, 17 Feb 2009 16:16:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.363
X-Spam-Level:
X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315]
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 tzKuZTF-U9Fs for <mmox@core3.amsl.com>; Tue, 17 Feb 2009 16:16:23 -0800 (PST)
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id 894B23A67A5 for <mmox@ietf.org>; Tue, 17 Feb 2009 16:16:23 -0800 (PST)
Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 17 Feb 2009 16:10:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.38,225,1233561600"; d="scan'208";a="666372636"
Received: from rrsmsx601.amr.corp.intel.com ([10.31.0.151]) by fmsmga001.fm.intel.com with ESMTP; 17 Feb 2009 16:20:26 -0800
Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Tue, 17 Feb 2009 17:16:33 -0700
From: "Hurliman, John" <john.hurliman@intel.com>
To: "mmox@ietf.org" <mmox@ietf.org>
Date: Tue, 17 Feb 2009 17:16:30 -0700
Thread-Topic: [mmox] The Story So Far...
Thread-Index: AcmRWWnen2oFhocMSlWtWUF9yiQyiAAAGEzw
Message-ID: <62BFE5680C037E4DA0B0A08946C0933D501FDCC8@rrsmsx506.amr.corp.intel.com>
References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <B8A94709-07E4-4FF8-B321-A4123E9DC633@lindenlab.com>
In-Reply-To: <B8A94709-07E4-4FF8-B321-A4123E9DC633@lindenlab.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
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: Wed, 18 Feb 2009 00:16:25 -0000

>-----Original Message-----
>From: Meadhbh Hamrick (Infinity) [mailto:infinity@lindenlab.com]
>Sent: Tuesday, February 17, 2009 3:42 PM
>To: Hurliman, John
>Cc: mmox@ietf.org
>Subject: Re: [mmox] The Story So Far...
>
>
>On Feb 17, 2009, at 3:09 PM, Hurliman, John wrote:
>
>>> While there is plenty to do and discuss in order to develop OGP
>>> into a
>>> fully workable protocol, we think it represents an initial shared
>>> vision
>>> of an interoperable protocol and hope it can evolve and grow in the
>>> context of this group.
>>>
>>> - Mark Lentczner
>>>
>>> [1] http://wiki.secondlife.com/wiki/Open_Grid_Protocol
>>
>> It's great to see the amount of work that is being brought to the
>> table by Linden Lab and the Linden Lab Architecture Working Group
>> (AWG) participants, and I hope as much of it as possible can be used
>> to build an MMOX standard. I've been working on an LLIDL
>> implementation among other things based on what Linden Lab has
>> submitted as draft material.
>
>awesome!
>
>> It's my understanding that Open Grid Protocol (OGP) is a Linden Lab
>> project; part of the Linden Lab AWG which had no active contributors
>> that were also active developers of libSecondLife/libOpenMetaverse
>> or OpenSim during the time the OGP protocols were designed. The
>> "agent domain" concept in OGP terminology brings in a host of
>> assumptions that are diametrically opposed to the goals of
>> libOpenMetaverse and OpenSim (supporting millions of independent
>> administrative domains and service providers).
>
>huh? there were a number of non-lindens who participated in the
>development of OGP. the AWG does not, nor did it ever disallow
>participation by libSL or libOMV contributors / committers. last
>summer we demonstrated interoperability between Linden Lab's servers
>and an OpenSim instance. we hope that members of the libSL and libOMV
>teams will participate in MMOX.
>

I said "AWG had no active contributors that were also active developers of libSecondLife/libOpenMetaverse or OpenSim during the time the OGP protocols were designed". The participation by individuals that were not Linden Lab employees does not mean that OGP is a joint effort between Linden Lab and the libOpenMetaverse or OpenSim projects, or that the OGP as it is drafted has support from the libomv/OpenSim communities.

>the concept of an agent domain was defined explicitly to support many
>different independent administrative domains. that is... though the
>interoperability test last summer used the Linden agent domain, the
>specification does not mandate a single agent domain. in fact, i
>believe Christian Scholz (a non-linden) implemented his own Agent
>Domain based on code from the PyOGP project. There is also frequent
>mention in AWG meetings of an upcoming C# implementation of an Agent
>Domain, again by a non Linden-Lab employee.

The agent domain concept takes several independent services (identity, presence, inventory) and lumps them together into a single trust domain. This inhibits the development of a widely distributed ecosystem like we find on the web today, and is really only convenient for large virtual world service providers that already have a vertical stack of services. It also drags in the assumption that there must be a backend communication layer between services such as inventory and simulation regions.

John