Re: [mmox] 3-world OGP interop scenario

jon. yes, we do believe it's a good idea to specify interaction  
between hosts in a standard protocol.

no. we do not believe it is appropriate for a protocol to specify a  
GUI, which is why the OGP designers did not include a GUI in the  
specification. You will note that there are also no sections in the  
standard limiting end points to use a particular format for the  
creation of scene graphs, nor is there a specification for how version  
patching for executable is to be accomplished. nor is there a  
specification for mapping arrow keys to RPC calls.

sorry to lose you to this effort, we look forward to seeing your work  
with LESS and MXP.

-cheers
-meadhbh

On Mar 12, 2009, at 11:55 AM, Jon Watte wrote:

> 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
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox