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

"Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com> Tue, 17 February 2009 23:42 UTC

Return-Path: <infinity@lindenlab.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 328FD3A6AF9 for <mmox@core3.amsl.com>; Tue, 17 Feb 2009 15:42:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.441
X-Spam-Level:
X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 RAbHA+pBQf0O for <mmox@core3.amsl.com>; Tue, 17 Feb 2009 15:41:57 -0800 (PST)
Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 4C64A3A6A8A for <mmox@ietf.org>; Tue, 17 Feb 2009 15:41:57 -0800 (PST)
Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 18AC7141405F; Tue, 17 Feb 2009 15:42:09 -0800 (PST)
Message-Id: <B8A94709-07E4-4FF8-B321-A4123E9DC633@lindenlab.com>
From: "Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com>
To: "Hurliman, John" <john.hurliman@intel.com>
In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Tue, 17 Feb 2009 15:42:08 -0800
References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com>
X-Mailer: Apple Mail (2.930.3)
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: Tue, 17 Feb 2009 23:42:01 -0000

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.

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.