Re: [mmox] Loosely Coupled Virtual Worlds
"Mystical Demina" <MysticalDemina@xrgrid.com> Fri, 27 March 2009 17:54 UTC
Return-Path: <MysticalDemina@xrgrid.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 C29E428C124 for <mmox@core3.amsl.com>; Fri, 27 Mar 2009 10:54:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.163
X-Spam-Level:
X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 5OWDrhraQSuL for <mmox@core3.amsl.com>; Fri, 27 Mar 2009 10:54:45 -0700 (PDT)
Received: from k2smtpout06-01.prod.mesa1.secureserver.net (k2smtpout06-01.prod.mesa1.secureserver.net [64.202.189.102]) by core3.amsl.com (Postfix) with SMTP id 92BBD3A6A3C for <mmox@ietf.org>; Fri, 27 Mar 2009 10:54:45 -0700 (PDT)
Received: (qmail 4502 invoked from network); 27 Mar 2009 17:55:33 -0000
Received: from unknown (HELO TWEEDY001.kevin-tweedy.com) (68.178.225.179) by k2smtpout06-01.prod.mesa1.secureserver.net (64.202.189.102) with ESMTP; 27 Mar 2009 17:55:31 -0000
Received: from KEVINPC ([173.49.10.182]) by kevin-tweedy.com with MailEnable ESMTP; Fri, 27 Mar 2009 10:55:27 -0700
From: Mystical Demina <MysticalDemina@xrgrid.com>
To: 'MMOX-IETF' <mmox@ietf.org>
References: <49CAAACF.8030208@gmail.com><e0b04bba0903260811s765643b1q5ffcb51ff0a90429@mail.gmail.com><62BFE5680C037E4DA0B0A08946C0933D72A1E3FC@rrsmsx506.amr.corp.intel.com><f0b9e3410903270702h102952f8t89da7052a70fd4f9@mail.gmail.com><C6197B866A3440CC9339834A812783C6@KEVINPC> <f0b9e3410903270928j7cae8a7eub778e8de6fb042f6@mail.gmail.com>
In-Reply-To: <f0b9e3410903270928j7cae8a7eub778e8de6fb042f6@mail.gmail.com>
Date: Fri, 27 Mar 2009 13:55:16 -0400
Message-ID: <E10E24B3ECFC47DF94E0A12CA5FCEF8D@KEVINPC>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01C9AEE3.A93B8830"
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acmu+Q3lNE9XT56ST+iUjhbOrphpCQACqF2Q
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049
Subject: Re: [mmox] Loosely Coupled Virtual Worlds
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: Fri, 27 Mar 2009 17:54:56 -0000
But not all inventories may originate from a virtual world. Or be from one virtual world. Just trying to open up what seems to be an assumed position. The current model also limits content providers and adds a lot of overhead and cost to content delivery and updates. For instance if I am a content provider will we require my customers to first upload their inventory into a specific grid before it can be used. What about updates and fixed? Would be much each if I simply upload my fix and all references to it are able to get the updated instead of this model in SecondLife where I have to distribute my product to every person that buys for them to rez it again, remove the old, all that kind of stuff. And then there is the content of dynamic content that will be changing as part of the service that is provided. Granted some of that may be done with scripting but I can see models where my content is specific to a user, to time a day, to other factors and different content would be provided by the same request for the inventory item. I respect your experience with OpenSim but having 15 years of internet experience and 27 years of software industry experience and I believe Darwin always wins in the end and to me that will be what ever the least costly, easiest model, quickest to implement solution that will ultimately be the direction. I would suggest the current direction isn't really addressing the cost and management of content and will not scale to 1000s of grids. Kevin Tweedy SL: Mystical Demain _____ From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of Charles Krinke Sent: Friday, March 27, 2009 12:28 PM To: Mystical Demina Cc: MMOX-IETF Subject: Re: [mmox] Loosely Coupled Virtual Worlds We have had this discussion on and off for a couple of years now on OpenSim regarding where objects should be stored. In general, it is argued that objects unique to an avatar are best stored in an avatar-unique manner, be that a home grid, a home region, or a USB thumb drive. But, also in general, it is argued that objects that need to be interacted with by *other* then the owner, need to be stored in a manner that allows this interaction. >From the OpenSim viewpoint, we have headed down a hybrid approach for grid objects or assets. Some assets are stored on the local region hard disk, some are stored on a gridserver complex if this region is part of a grid. >From the interop viewpoint, I would think each virtual world, or instantiation of a software that supports a virtual world would need to deal with this with their own vision in mind. I would not presume to tell SecondLife how they should or should not store objects and assets. For the purpose of this group, I would tend to focus on how we may interact with other existing virtual worlds implementations such as chat, teleport, presence and devolve the asset storage for the most part back to the architecture making up the virtual world. Charles Krinke OpenSim Core Developer OSGrid Director 2009/3/27 Mystical Demina <MysticalDemina@xrgrid.com> I just wanted to add I can see the agent being on the same computer that is running the rendering which would typically being a client which would know how to pass any needed references to one ore more locations inventory could be utilized from, including my local disk. Although not sure why the simulator would need access to inventory, seems this agent will handle any request for a particular object and provide it to the simulator which would allow inventory to come from any other computer in the world. Or this agent may be a proxy for my client who would run on a server I am logged into and handle these negotiations. It is my opinion we need to move past the idea of the inventory being something owned by a grid and more to a source of an objects that I have access to that can be used into a simulator. This object(s) could be copied and cached into the simulator or it could be a proxy, and to some degree at least some if it probably need to be, it can be a shell of the object that is actually instantiated somewhere else and provided once or updated in a steam of information that could be multiple times a second or long term like daily or more; or event driven. Some thoughts. Kevin Tweedy SL: Mystical Demina _____ From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of Charles Krinke Sent: Friday, March 27, 2009 10:02 AM To: Hurliman, John Cc: MMOX-IETF Subject: Re: [mmox] Loosely Coupled Virtual Worlds I think what is happening here is we have half of a solution that needs a bit more symmetry. A citizen from a SecondLife grid can certainly connect today to an OpenSim grid or standalone using the Agent Domain notion. But, a citizen from an OpenSim grid such as OSGrid cannot cannot to a SecondLife grid in a symmetrical fashion as there is no Agent Domain notion in OpenSim. I look at this and think more along the lines of passports and border crossings between virtual countries. Using this metaphor, there needs to be a handoff of an avatar from one grid to another grid for simulation. Now, I can see some notions of a circuit connected back to ones home grid for certain authentication and object inventory issues, but in general this is a border crossing between countries. When I mean symmetry, I also mean that a citizen of a SecondLife grid may enter a region on OSGrid, but similarly, I would expect a citizen of OSGrid to be able to enter a SecondLife grid. Else this interoperability is one way and not advantageous to both parties. Charles Krinke OpenSim Core Developer OSGrid Director On Thu, Mar 26, 2009 at 6:17 PM, Hurliman, John <john.hurliman@intel.com> wrote: >-----Original Message----- >From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of >Morgaine >Sent: Thursday, March 26, 2009 8:11 AM >To: Jason Giglio >Cc: MMOX-IETF >Subject: Re: [mmox] Loosely Coupled Virtual Worlds > >On 2009/3/25, Jason Giglio <gigstaggart@gmail.com> wrote: > > > http://www.meerkatviewer.org/whitepaper.pdf > http://www.meerkatviewer.org/whitepaper.odt > > > > >The above document seems remarkably insightful on various fronts: > ... > >* Indirectly, it highlights that the Agent Domain model does not >have a solution to the problem of accessing worlds with which there is >no trust agreement. People will want to enter arbitrary worlds, and >therefore that restriction is inadequate. >* There will be millions of worlds in an Internet-scale metaverse, >which makes the concept of interop through trust agreements far too >narrow. Trust loses its meaning entirely when scaled to millions, >becoming mere paperwork or "security theater". This is, in my opinion, the fundamental flaw in OGP. Explicit trust maps (whitelists) work great when IBM wants to define policy to connect to the Linden Lab grid, but has no meaning and no hope of scaling when you talk about defining trust for millions of simulation grids and millions (or at least thousands) of identity providers. This is the primary reason that Intel and many members of the OpenSimulator/OpenMetaverse community have not considered OGP as a strong proposal for virtual world interoperability. If this understanding is not accurate, it would be helpful if an OGP author could step in and clear up the confusion. John _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox -- Charles Krinke OpenSim Core Developer OSGrid Director _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox -- Charles Krinke OpenSim Core Developer OSGrid Director
- [mmox] Loosely Coupled Virtual Worlds Jason Giglio
- Re: [mmox] Loosely Coupled Virtual Worlds Gareth Nelson
- Re: [mmox] Loosely Coupled Virtual Worlds Morgaine
- Re: [mmox] Loosely Coupled Virtual Worlds Hurliman, John
- Re: [mmox] Loosely Coupled Virtual Worlds Charles Krinke
- Re: [mmox] Loosely Coupled Virtual Worlds Mystical Demina
- Re: [mmox] Loosely Coupled Virtual Worlds Charles Krinke
- Re: [mmox] Loosely Coupled Virtual Worlds Mystical Demina
- Re: [mmox] Loosely Coupled Virtual Worlds Morgaine