Re: [mmox] The Story So Far...

["Hurliman, John" <[e-mail]>]

>-----Original Message-----
>From: Jon Watte [mailto:[e-mail]]
>Sent: Wednesday, February 18, 2009 9:54 PM
>To: Hurliman, John
>Cc: [e-mail]
>Subject: Re: [mmox] The Story So Far...
>
>Hurliman, John wrote:
>> include anything like that. Instead, a teleport is done from grid A to
>grid B where identity and appearance are the only things that need to
>persist. I don't see why grid<->grid communication is fundamentally
>necessary to transfer identity and appearance.
>>
>
>At least three reasons:
>
>1) When I am logged into a virtual world, it's usually for a reason. For
>me, it's work -- my virtual world allows me to cooperate with remote
>workers, visualize 3D data, and have meetings that are more effective
>and cheaper than conference calls. (Customers love "cheaper" :-) If I
>were to log off my "home" virtual world, then I would lose some or all
>of those capabilities while I "went elsewhere." For example, if my
>company has a policy of recording all interactions in the world, for
>regulatory compliance, if I suddenly disconnected and connected to
>another grid, that function would not be present.
>

I visit my internal homepage at intel.com and browse several other parts of the web at the same time. It doesn't require any established trust between intel.com and the rest of the web.

>2) Object behavior is not portable. One system may use SecondLife Script
>version 2.3 for its objects. Another may use Java Runtime 1.5.6. A third
>may use Visual C++ 9.0 linkable libraries.
>

Just as some websites are powered with PHP, some use Java backends, and some have bits written in C++?

>3) If you "grid hop" to another location, you have to have a client that
>can connect to whatever server protocol that location is using. Writing
>a "universal client" has proven to be quite quixotic for two reasons: a)
>Any real system will have to have a "home protocol" anyway to provide
>functionality not provided for in the standard, and b) re-implementing
>virtual world presence for a client as a separate channel only to use
>for interoperability isn't a good idea.
>

I agree that the universal client solution is not an answer to interoperability. However, this seems to just be pushing the problem back to the server. Instead of a universal client we'll have a universal server that can do universal protocol translation. What if this universal server was ran on localhost? Would it become a universal client?

>
>If I "grid hop," I might as well just have two clients installed (one
>that uses ClosedGardenWorld protocol 1.3, and one which uses
>WalledSpacesWorld protocol 2.7), and launch the right client for where I
>want to go -- the "benefit" of interoperability would be quite marginal;
>basically just not having to fill out a registration form for each
>world. No business will do a lot of engineering work to enable a
>scenario like that, because it delivers very little added value.
>
>Sincerely,
>
>jw

I think it's arguable whether merging the view of two worlds together has higher value than teleporting presence and content between worlds.

John