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

[Jesrad <[e-mail]>]

> 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.

Yes, that's what I was talking about: the common protocol is really a
standard remote-API that VWs should conform to when communicating with
clients - a conveyor of relevant information but not the information
itself. By making an object a pure stack of references (one reference
per Grid service to be used) then the format of these references and
the external object they point at can be expanded upon very easily
afterwards.

Furthering this view, a VW then does just one minimal function:
connecting the dots. A Grid becomes little more than a router for the
relevant references/info, in this model. Some Grids may internally
host the objects refered to (the 3D data, the sound files ,etc...) and
apply access control, while some others might depend entirely on
external hosting (we could have clients that fetch textures through
plain HTTP, references could even point to local files for games that
have static content) and let the client end handle authentication, but
in the bigger picture then it's only the end clients and the
hosts/sources that are being connected together through the grids,
while these underlaying grids affect the content very little: they'd
be acting on the connection only.

The bare minimum a VW does, then, is transmitting just the presence
signal between congruent entities, so each of them knows "who's there"
depending on this "there". Additional functions and signals can be
internally hosted and/or signalled on a per-grid basis, like with MIME
codes for the Web. That makes the interoperability protocol into some
sort of service location and discovery protocol, I think.

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

Javascript ? Flash ? I think they owe their heavily cross-platform
usage more to the market they're used in, than to any special
characteristic they may have as languages. And that this market
resembles VWs more than the general professional software industry
does, so I don't see why we shouldn't expect the same for VW
scripting.

On Thu, Feb 19, 2009 at 1:23 PM, Kajikawa Jeremy <[e-mail]> wrote:
> 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
>