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

[Charles Krinke <[e-mail]>]

This seems a very reasonable direction and discussion. Let me toss in the current OpenSim direction as a reference. 

We tend to like five server processes currently and these are split into a UserServer, GridServer, AssetServer, InventoryServer and MessagingServer.

As the situation evolves, and we seek and find a consensus, I see one of the necessary steps to finding a consensus that everyone be willing to describe and negotiation a common ground. So, thinking about Wow, Croquet & Wonderland interop with SecondLife and OpenSim seems to me a good direction to focus as it will probably allow us to get to the "what" and "how" of the plumbing and past the "why" perhaps more quickly.

Charles


________________________________
From: Kajikawa Jeremy <[e-mail]>
To: "[e-mail]" <[e-mail]>
Sent: Wednesday, February 18, 2009 5:24:54 AM
Subject: Re: [mmox] The Story So Far...

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" <[e-mail]>
> To: "[e-mail]" <[e-mail]>
> Sent: Tuesday, February 17, 2009 4:16:30 PM
> Subject: Re: [mmox] The Story So Far...
> 
> >-----Original Message-----
> >From: Meadhbh Hamrick (Infinity) [mailto:[e-mail]]
> >Sent: Tuesday, February 17, 2009 3:42 PM
> >To: Hurliman, John
> >Cc: [e-mail]
> >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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox
> 
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox