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

[Jesrad <[e-mail]>]

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

The way I see it, we're trying to figure out how the "language" that
different VWs could use to exchange their common types of data.

So first we should be figuring out what data types and features are
common to the VWs/MMOGs targeted. Obvious ones (2D/3D representation,
identity referal + authentication, experience/level/gold/L$ account,

Then we classify these data types into a few major supertypes that
each correspond to a basic grid service (can they be optional or not
?), a bit like how the Agent Domain includes IM, L$ and inventory: WoW
players also have IM, gold, and inventory, and that can be considered
the "WoW Agent Domain".

In this way we can design containers for each supertype, seperately.
The basic, universal operation of a VW (connecting the dots, see
previous message) dictates the logic of the protocol, while the data
types dictate the content/streams it transports. The idea is that each
supertype of data may be supplied by different grids at the same time,
so each shall regroup only the features and data subtypes that mandate
each other: you're supposed to be able to login in your SL account
then enter the OSGrid, while retaining your SL L$ balance.

Tentative adoption plan:

Step 1: Existing VW are expected to encapsulate their own protocols
into this common grid protocol, as an additional layer on their
existing protocols

E.g. sending an object to the viewer becomes contained in the
supertype container for "object".

Step 2: Support for different data format can be added between this
new layer and the existing ones, for each set of grid server + client:
at this step, for example, it becomes possible to display previously
unsupported 3D models, or to hear the . We'll have to figure out where
the conversion is done (at the source or end-point or gateway ?)

E.g. you download/buy an add-on for the SL viewer that lets it render
the WoW avatar model it may receive in an "object" supertype container
instead of the usual SL definition, by reading the static data it
refers to.

Step 3: at this point there is already basic interoperability, which
can be expanded upon by switching to common format for the actual data
transmitted. Specific exchanges between VWs can be set up to allow
more interoperation (like an exchange between L$ and WoW gold so you
can pay L$ in WoW and vice-versa).

If we devise a "native" format for "common denominator" data types,
step 3 would be the time where VWs switch to this native format from
their previous incompatible ones.

This whole proposal assumes there IS a basic, universal operation that
all VWs/MMOGs do respect.

On Thu, Feb 19, 2009 at 4:55 PM, Charles Krinke <[e-mail]> wrote:
> 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.
>
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox
>
>