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

Kajikawa Jeremy <belxjander@gmail.com> Wed, 18 February 2009 13:30 UTC

Return-Path: <belxjander@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 CF5C23A6CC3 for <mmox@core3.amsl.com>; Wed, 18 Feb 2009 05:30:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.377
X-Spam-Level:
X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, 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 XNam1tYomit3 for <mmox@core3.amsl.com>; Wed, 18 Feb 2009 05:30:00 -0800 (PST)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 321A33A69CC for <mmox@ietf.org>; Wed, 18 Feb 2009 05:30:00 -0800 (PST)
Received: by rv-out-0506.google.com with SMTP id l9so2416345rvb.49 for <mmox@ietf.org>; Wed, 18 Feb 2009 05:30:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; bh=mzFG8pfAp47pgJ/eYmKdr1JbjXz1bkZXWU+5FQcDC6E=; b=qqfORe3aIvWq9Mdu0Kng6BcTyEwslw7q64cFTm164THKPKfkOa1F5lCD5XvxSZxMYq 41F3k871g7fTUB5TGD04OQpb7sG7y1A6Ly9AHevIauGU3dDynq4poyVOd/rxP1mwFBk9 WRWtPo27Z1JQ+bpwM5/hYCcvcsvMCS2lLH2E0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:disposition-notification-to :content-type:date:message-id:mime-version:x-mailer; b=wIOJASj7Ay+fa2bzCn5WhXMRYt7DfktVlCeD0CaKl4OFwGt5JVy5mns3wDXqV/hL4m RKSGvhmImyQFPP47/Mtk6wZPmP+GA6bwAmAsqubVP/VHdF5ok5VqrwYwELtiyGZqWP3c 8997K/vlJl6mY1Z5NWZ/e/FvvJEdX/cVVF8L8=
Received: by 10.141.142.15 with SMTP id u15mr3979705rvn.16.1234963811902; Wed, 18 Feb 2009 05:30:11 -0800 (PST)
Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id b8sm16830506rvf.8.2009.02.18.05.30.09 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 05:30:10 -0800 (PST)
From: Kajikawa Jeremy <belxjander@gmail.com>
To: "mmox@ietf.org" <mmox@ietf.org>
In-Reply-To: <306449.42147.qm@web82603.mail.mud.yahoo.com>
References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <B8A94709-07E4-4FF8-B321-A4123E9DC633@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDCC8@rrsmsx506.amr.corp.intel.com> <306449.42147.qm@web82603.mail.mud.yahoo.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-6e14Q9ioceELW48XpqKE"
Date: Wed, 18 Feb 2009 22:24:54 +0900
Message-Id: <1234963494.7560.8.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
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 13:30:05 -0000

Then the Minimum "plumbing" would be
 "User Account" and "User Presence" along with some kind of 3dspace with
  "object"s present that are not a "User Presence"...

in SL terms this would be "grid"/"users" and "asset/inventory" functions
required,

in WoW terms,  a "User Account", the "Game Arena" server and then the
  Users "Item Storage" for Items picked up in the "Game Arena".

3 parts,
  1 "human" Presence and Identity,
  2 some kind of "mappable area" that is shared,
  3 interactable "objects" present in the "mappable area".

Any client functionality would be at bare minimum that and would need to
make a display
  representing the map and objects in it. would it not ?

the "AgentDomain" and "User" Services from SL would be merged for
Identity & Presence,
the "Grid" & "Region" services also appear to merge,
the "Assets" & "Inventory" services also appear to be merged,
as for messaging,  each platform has so far implimented this in some
fashion as an extended
  feature of presence,  I vote to keep this an open binding option
allowing choice of backend

does anyone see any problems with my simplification in the above 3 parts
listing?

On Tue, 2009-02-17 at 16:23 -0800, Charles Krinke wrote:
> As I think about virtual worlds and interoperability, the metaphor of
> independent states or nations come to mind. So, I guess in thinking
> about interop between virtual worlds, we can either go down the
> secondlife/opensim type of path and try to fit all virtual worlds into
> that paradigm with agentdomains or UGAIM notions or we could step back
> a bit and consider interop between
> secondlife/opensim/Wow/croquet/wonderland and others.
> 
> Is is appropriate to start at a higher level and take a step back and
> consider the broader implications of virtual worlds beyond just our
> current paradigm such as WoW/croquet/wonderland and identify the
> minimum definition of network "plumbing" with that in mind?
> 
> Charles
> 
> 
> 
> ______________________________________________________________________
> From: "Hurliman, John" <john.hurliman@intel.com>
> To: "mmox@ietf.org" <mmox@ietf.org>
> Sent: Tuesday, February 17, 2009 4:16:30 PM
> Subject: Re: [mmox] The Story So Far...
> 
> >-----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
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
> 
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox