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

I'd say the same can be said of anything related to any object but not
being the object itself: just as the "script" of an object should be
communicated between grids as an external reference, so should the 2D
or 3D representation, the sound/stream, the text stream, etc.

E.g. I drive my virtual car through a portal to another grid: the
information exchanged is just a stack of references: a ref to its 3D
representation (CAPS ?), a ref to the running script, a ref to the
Agent Domain (for ownership, controls, access rights, whatever), a ref
to the source grid, etc... all of those to be accessed by the
destination grid.

That stack of references, at the MetaGrid level and in itself, "is"
this virtual car owned by me at this place and time and is
interoperable to the extent that the VWs can handle these types of
references (and their respective clients can display them, but that's
something else). A translation table can be established at the object
level for supplying different refs to different grids (I have 3D
models in mind here), maybe that makes one more reference in the
stack.

In this view the only interoperability that needs to be coordinated
between the VWs, is that of uniformity of access, like with a
standardized API.

The problem I see here is that in this model, internal scripts for
objects need to be accessed uniformly, too. When my car bumps into
something and is scripted for that event, both grids need to be
capable of calling the right event handler.

On Thu, Feb 19, 2009 at 1:24 AM, Jon Watte <jwatte@gmail.com> wrote:
>
> I think the lowest common denominator may be aiming too low -- we need to
> deliver actual value to actual end users paying for that value, or the whole
> effort is moot.
>
> However, that being said, I'm prepared to throw a stake in the ground: You
> cannot migrate behavior.
> If behavior is authored for system X, then system Y will not be reasonably
> expected to perform that behavior at full fidelity. For example, behavior
> could be written in Java for Wonderland, or Python for Qwaq or Panda3D, or
> C++ and XPath for OLIVE. There simply is no way that every virtual world
> will be capable of emulating the execution environment of each other virtual
> world (here's a case where X3D broke down -- it specified an execution
> environment, that didn't actually suit anyone's needs).
>
> Thus, to make an object appear in a "remote" world, that object needs to be,
> at a minimum, simulated in the "home" world, and information about the
> outcome of that simulation (animations played, movements performed, sounds
> generated, interactions caused, etc) should be transmitted over the
> interoperability channel.
>
> Sincerely,
>
> jw
>
>
> Charles Krinke wrote:
>>
>> So, it behooves us to find that lowest common denominator and see if we
>> can create a useful specification to avoid wasting any of our time. I have
>> to believe that there exists a subset of the SecondLife OGP and HyperGrid
>> notions that can at least form a basis to start building. If not, perhaps
>> someone can propose such a basis.
>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
>