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

[Kajikawa Jeremy <[e-mail]>]

But any transfer of objects outside being part of the AV itself I would
consider to be
  either subject to breakage or likely to come across with dataloss in
function.

this also reads to me as requiring the following...

Each "System" is developed independently and a common library is
developed (akin Java)
 for a write-once run-anywhere specification where the backends use each
systems local
 implimentation of any given functionality,  and also the requirement of
specific support.

How many developers actually use Java/Python/... as cross-platform
development,

currently WoW has LUA for scripting the client,  SL has LSL and this is
scripting independent
 of the client and running on the server as well as "attachment" scripts
for extending the AV
 functionality with client-side UI presence.

Therefore I suggest a middle-path... allow each system to select its own
scripting language,
  and only require a "common library" of functionality presence with
cross-binding option.

That way anyone who impliments anything can rely on the functionality at
scripted level
 remaining stable on the originating grid, (LSL already has C# and C
language editions)

I see the interoperability needing support from those systems making it
available.

I do see one point of contention that will break this occuring,  what to
support first?

How about presence alone and simply do not provide any mechanism for
import/export
  of materials across worlds that are containing any "script" or
executable content.

disconnect that into an own server and make the functions required
follow the KISS rule,
  the more that is applied the more successfully available interop will
become. 

For now scripting will have to be "future"...basic shapes and "look" on
objects need to
 follow getting AV transfer occuring without the entire legal mess
considering...

 Guild Wars and some other games dont licence the engine but instead the
content,
  and this content would need to have downgraded editions available for
non-licensed
  viewing so some kind of system<->system remapping WILL occur
somewhere.


On Thu, 2009-02-19 at 12:38 +0100, Jesrad wrote:
> 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 <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmox
> >
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox