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
- [mmox] A tentative top-down analysis Jesrad
- Re: [mmox] A tentative top-down analysis Morgaine
- Re: [mmox] A tentative top-down analysis Jon Watte
- Re: [mmox] A tentative top-down analysis Christian Scholz
- Re: [mmox] A tentative top-down analysis Jon Watte
- Re: [mmox] A tentative top-down analysis Christian Scholz