Re: [mmox] A tentative top-down analysis

Christian Scholz <cs@comlounge.net> Thu, 26 February 2009 23:21 UTC

Return-Path: <cs@comlounge.net>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914BF3A68F4 for <mmox@core3.amsl.com>; Thu, 26 Feb 2009 15:21:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.416
X-Spam-Level:
X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DArfTmFjYd37 for <mmox@core3.amsl.com>; Thu, 26 Feb 2009 15:21:40 -0800 (PST)
Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 1AB1A3A6767 for <mmox@ietf.org>; Thu, 26 Feb 2009 15:21:40 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 9A7481CE029D; Fri, 27 Feb 2009 00:22:01 +0100 (CET)
Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1RasznWcLOz; Fri, 27 Feb 2009 00:22:01 +0100 (CET)
Received: from [192.168.2.101] (pD9EBC236.dip.t-dialin.net [217.235.194.54]) by post.comlounge.net (Postfix) with ESMTP id 085C21CE0001; Fri, 27 Feb 2009 00:22:01 +0100 (CET)
Message-ID: <49A72419.70904@comlounge.net>
Date: Fri, 27 Feb 2009 00:22:01 +0100
From: Christian Scholz <cs@comlounge.net>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Jon Watte <jwatte@gmail.com>
References: <53cd6c2e0902260734t7336df2dp2a97bd93b5db792b@mail.gmail.com> <e0b04bba0902260933r4ce08169x1b324a0efae5c80e@mail.gmail.com> <49A6E86D.9040906@gmail.com>
In-Reply-To: <49A6E86D.9040906@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "mmox@ietf.org" <mmox@ietf.org>
Subject: Re: [mmox] A tentative top-down analysis
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Feb 2009 23:21:41 -0000

Jon Watte schrieb:

> That's right! Incidentally, this matches almost exactly the "connected 
> server peers" model that I've been proposing.
> 
> However, the objects themselves are owned by one of those N providers 
> (or else why is the provider supplying authoritative state for it?)

But I want to own my data :-) I might give you a license though to host 
it for me. But actually I should also be able to host my own inventory 
and simply give you the URL to it (which in fact might be a simple web 
server).
So there could even be simple hosting servers which are dumb regarding 
the whole VW thing and simply host objects without ever doing any 
simulation.
And I can simply put those URLs into my users's service catalogue to be 
discovered by some simulator.

>> What's more, those updates will often need to continue even when (i) 
>> the avatar is currently offline, and when (ii) the items are dispersed 
>> across many other worlds, and when (iii) the avatar is currently in a 
>> world with which they do not have direct interop.
>>
> 
> Saying that the object update persists in the simulation when you don't 
> have interop with the viewer is like saying that you can browse the 
> YouTube video library when you have disconnected your Internet 
> connection. I don't think that would be realistic.

Well, I can browse my podcast collection. It's just a question of how 
you define caching.

> 
>> The last point is particularly revealing:  provider A may have an 
>> explicit agreement to interoperate with provider B, and provider B may 
>> have an agreement with provider C, without A and C having any direct 
>> agreement whatsoever.  Yet, an avatar registered on B and wearing an 
>> unencumbered object from A will naturally be visiting world C, and the 
>> worn object must continue to fulfil its normal purpose or interop has 
>> failed.
>>
> 
> Agreed!

Well, we thought a bit about this chaining of trust (if it comes to the 
creator's will) and it might be problematic depending on what choices 
you want to give the user and the creator. As a creator you then can 
never be sure where that object goes. But it's maybe mainly a question 
if you allow it to leave the originating VW or not. If you choose not to 
you are more safe apparently than if you choose to allow it (but might 
make more sales).
But of course from a technical perspective I agree. It should 
potentially work in C.

-- Christian


-- 
Christian Scholz
Blog: http://mrtopf.de/blog
Company: http://comlounge.net
Podcasts: http://datawithoutborders.net, http://openweb-podcast.de