Re: [mmox] User Accounts / "Object" Transfer.

[Charles Krinke <[e-mail]>]

Dear Morgaine:

That could very well be. Shared spaces may or may not be achievable in the near term.

That sort of gets us back to figuring out what we "do" wish to accomplish. 

Are we here to seek consensus and modify the already existing and deployed OGP protocol of SecondLife? Are we here to see if HyperGrid from OpenSim is appropriate for this group? Are there other protocols to consider?

So, I have to ask, as I am getting confused with all the e-mails flying around and like many, I have lots of things to concentrate on. So:

"What are we here for and what do we hope to accomplish?"

Charles




________________________________
From: Morgaine <[e-mail]>
To: Jon Watte <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Sent: Thursday, February 19, 2009 7:36:54 AM
Subject: Re: [mmox] User Accounts / "Object" Transfer.




On Thu, Feb 19, 2009 at 12:37 AM, Jon Watte <[e-mail]> wrote:



Let's assume organization A builds a space. Let's assume organization B builds furniture. Now, they want to have a meeting, and see how the furniture works in the space. The easiest way to accomplish this is to make organization A users log into the organization A virtual world (like they always do), and organization B users log into organization B virtual world (like they always do), and make arrangements such that some room/area/island within the two organizations is shared -- whatever comes to that space from A, also shows up in B, and vice versa. This allows A to publish its space, and B to bring the furniture to that space, without either having to disconnect from their regular virtual world (buddy list, unified messaging, inter-office collaboration, etc).
Unfortunately, that's non-scalable, particularly along the complexity axis.

It works fine in your example because you have only two parties wishing to share a space and hence there is only one space to simulate, but try to extrapolate from there to see where it leads.  If your organization A has N users, and those N users wish to take part in N different worlds (which is asymptotically likely if N << total number of worlds), then your organization A must now simulate N different worlds.  For large N, this places a colossal load on organization A, even if the individual shared spaces are minimally populated.  To coin a common phrase by analogy, you're undertaking to "simulate the Internet". ;-)

What's more, very few platform optimizations will be possible since the N
worlds are all different, and this also means that the scalability of
each shared space will be severely constrained as well.  And as if that were not bad enough, the N worlds that your users visit tomorrow will not necessarily be today's N worlds, so for (N << total number of worlds) your local cache will need to grow almost without limit if it's to work at all.

Even if organization A's machinery were powerful enough to support N radically different worlds through shared-space simulations though, they still couldn't do it, because in the general case the simulation code for a given world will not be available.  The world simulation is the "secret sauce" of many virtual worlds, and from a business perspective it is quite likely to be their product differentiator and they will be loathe to share it.  But even if it were freely available, the portability of one organization's simulation code to another organization's machinery is far from guaranteed with today's software technology, not to mention the management of upgrades for something this complex across organization boundaries.

Now contrast that shared-space architecture to today's more prevalent one.  Organizations A and B(1)...B(N) design their own worlds in accordance with their particular visions, and each world is tailored to their own optimized hardware.  Now in the case when the N users of organization A travel to those N different B worlds, organization A has no world simulation load for active users at all (it just sends out data to the N worlds).  Instead, some number of foreign users from the B worlds will arrive and need to be supported.  However, they are supported in organization A's own world simulation, which is highly optimized by design and hence carries none of the complexity/scalability problems mentioned above in the shared-space approach.  Foreign world simulations never need to be supported.

In the Internet-like metaverse model of unlimited and extremely diverse worlds, I really don't see the shared-space approach as being at all viable, because diversity is its enemy.  In some severely constrained corporate settings it might be quite usable (and even efficient for standardized worlds), but this does not seem to be a generally scalable model for an evolving metaverse.

Morgaine.