Re: [mmox] Chartering for requirements only

[Jon Watte <[e-mail]>]

Hurliman, John wrote:
> OGP is dodging the interoperability problem with explicit trust maps (http://software.intel.com/en-us/blogs/2009/02/18/approaching-virtual-world-interoperability/). 

I think the difference is deeper than that. In OGP, as far as I can 
tell, three entities all need to share a known representation of objects:
The object implementation (avatar, etc) as it comes from the object 
repository
The simulation server, where the object is injected
The client, that observes the simulation and presents it to the user

In this model, even if I implement OGP on the OLIVE side, OLIVE cannot 
interoperate with anything else. The only interoperability you get is if 
your client, server and object execution environment happens to be 
compatible with whatever target system you are attempting to 
interoperate with. In practice, this is only the case for Second 
Life-derived technologies in their own sphere, Unreal3-derived 
technologies in their own sphere, OLIVE-derived technologies in their 
own sphere, etc. Thus, no cross-technology interoperability is actually 
achieved, and thus I think it is misleading to label OGP a vendor 
neutral interoperability protocol. When actually implemented, it does 
not provide vendor neutral interoperability, it only provides vendor 
specific interoperability.

Additionally, the model of OGP does not scale well for larger 
interoperability scenarios, where multiple users from multiple different 
systems all want to interoperate, because all those users need to be 
injected on the same host. The LESS approach is one of bridging separate 
simulation servers into the same physical space, and thus scales a lot 
further.

It's unfortunately not very explicit in version 00 of the LESS 
description (http://tools.ietf.org/html/draft-jwatte-less-protocol-00), 
but the model is this:

1) User A logs on to system A (say, OpenSim) and invites user B using 
undefined means
2) User B logs on to system B (say, OLIVE) and accepts the invitation 
using undefined means
3) The B system sets aside some "empty space" on a simulator, places 
user B there, and then starts peering with system A
4) The environment and objects from system A, as well as user A himself, 
is peered to system B using LESS.
5) The objects and user from system B is peered to system A using LESS.

This means that both users see a collective simulation, where some 
objects are homed on A, some objects are homed on B, and they all 
interact. The nice property of this system is that it will scale very 
far, because objects are only simulated on their home systems. Further, 
it requires no changes to any clients of any participating system, 
because the presentation from system to client can be whatever it 
already is, as translation happens on the server-side LESS 
implementation level. (For p2p systems, view them as servers with a 
display stuck into the brain stem :-)

Please feel free to ask for clarification if there's something in this 
model that you find confusing. I have described this model several 
times, but each time I describe it, some new person tells me something 
along the lines of "Oh, now I get it -- that seems simple and useful. I 
hadn't thought in those terms before." I figure if I describe it often 
enough, in terms varied enough, perhaps in the end almost everyone will 
actually understand what I'm saying :-/

Sincerely,

jw