Re: [mmox] A tentative top-down analysis

Christian Scholz <cs@comlounge.net> Thu, 26 February 2009 23:37 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 B31393A68CD for <mmox@core3.amsl.com>; Thu, 26 Feb 2009 15:37:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.43
X-Spam-Level:
X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 tzXiV5u7Temw for <mmox@core3.amsl.com>; Thu, 26 Feb 2009 15:37:14 -0800 (PST)
Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 756263A68F4 for <mmox@ietf.org>; Thu, 26 Feb 2009 15:37:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 03D7C1CE03D5; Fri, 27 Feb 2009 00:37:36 +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 7LF0twM3rzBN; Fri, 27 Feb 2009 00:37:35 +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 305701CE0001; Fri, 27 Feb 2009 00:37:35 +0100 (CET)
Message-ID: <49A727C0.8010002@comlounge.net>
Date: Fri, 27 Feb 2009 00:37:36 +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> <49A72419.70904@comlounge.net> <49A726D1.4000404@gmail.com>
In-Reply-To: <49A726D1.4000404@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:37:15 -0000

Jon Watte schrieb:
> Christian Scholz wrote:
>> 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 :-) 
> 
> Sorry, I'm confusing the terminology here. The server "owns" the object 
> in the sense that it is the authoritative source of property values for 
> that object. I did not mean to imply any ownership in the IP sense, 
> because that discussion does not apply to the particular technical 
> details we're talking about; it's handled at a different layer.

Ok, we should define some terminology at some point anyway.

>> 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.
>>
> 
> Unfortunately, simulators use different scripting languages, execution 
> environments, APIs and architectures. Thus, you may be able to have a 
> dumb server (like a web server), but it could only serve an object to, 
> say, a Second Life-compatible server, or a Metaverse-compatible server, 
> unless the behavior of the object was re-developed for each simulation 
> platform.

Or it could provide different versions. Sort of like content negotiation.

-- Christian




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