Re: [mmox] 3-world OGP interop scenario

[Ann Otoole <[e-mail]>]

Actually this is all moot anyway since Worlds.com CEO Thom Kidrin is on a slash and burn Sherman March To The Sea lawsuit binge and there will be no 3D internet outside of Worlds.com if he wins. So the first order of business needs to be putting him out of business by defeating his patent or by moving this entire effort to a country that does not recognize U.S. Patent Law.

Re: http://www.massively.com/2009/03/12/world-of-warcraft-and-second-life-are-next-says-worlds-com-ceo/




________________________________
From: Jon Watte <[e-mail]>
To: Rob Lanphier <[e-mail]>
Cc: MMOX-IETF <[e-mail]>
Sent: Thursday, March 12, 2009 2:55:38 PM
Subject: Re: [mmox] 3-world OGP interop scenario

Rob Lanphier wrote:
> Yes, one can assume client A can talk to servers B and C if we actually
> go about the work of defining a standard client-server protocol spelling
> out how the client is expected to behave in that transaction.
>  

Do you seriously think it's a good idea to specify all the minutiae of how a server and client interact, as a standard protocol? Including how GUI is tied to local and remote capabilities, how a scene graph is constructed and animated, how version patching is done, how user control is forwarded, etc?
And all that work, just to be able to show up in world B instead of world A? What about objects you want to use cross worlds; are you saying you also want to specify the exact runtime requirements for objects (scripting language, physics interface, etc)?

Personally, I believe that trying to do that means that there will be no cross-world interoperability except for the worlds that share the same DNA (meaning SecondLife <-> OpenSim, and perhaps ActiveWorlds <-> Worlds.com, and perhaps OLIVE <-> There.com). I think that would be a huge loss. Additionally, I think that all of that effort will actually not solve any problem that users care about, because all it really solves is saving users from having to install an extra client. But even in the ActiveWorlds <-> Worlds.com scenario, or the OLIVE <-> There.com scenario, because the platforms share technology DNA, using OGP is probably more work than it's worth, because there is already an existing infrastructure that is less resistance, and achieves the same amount of interop. OGP doesn't help interop, in this case, except for the Second Life <-> Open Sim case.

Meanwhile, I believe that the real enabler of interop is to be able to merge the simulations of different worlds, something like LESS or MXP. If you think about it, that model actually provides the same benefit you seek: the user being able to visit other places. It even provides the benefit of the user not having to install more than one client, ever, as long as the user's "home" world (or "virtual world service provider" if you will) is interoperable. However, it also provides the benefit of being able to use a There.com car, while letting ActiveWorlds users see you do that (and perhaps even ride the car). Also, the LESS/MXP approach requires much less engineering to implement for the majority of world vendors. I know this from experience, having done it for different protocols in the past.

Thus, if the goal is general virtual world interoperability, I believe the OGP model does not achieve it, whereas the LESS and MXP model does.

If the goal is to make systems with Linden Labs DNA interoperate, such as Open Sim or RealXTend, then I suggest that you state that as an explicit goal. I believe the feedback you're getting right now is that OGP, as proposed, is not suitable for interop outside that technology sphere.

Sincerely,

jw

_______________________________________________
mmox mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmox