Re: [ogpx] one virtual world, or many?

Carlo Wood <carlo@alinoe.com> Sun, 30 August 2009 23:24 UTC

Return-Path: <carlo@alinoe.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE83B3A6D50 for <ogpx@core3.amsl.com>; Sun, 30 Aug 2009 16:24:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.354
X-Spam-Level:
X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745]
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 41PAkNHHK9hp for <ogpx@core3.amsl.com>; Sun, 30 Aug 2009 16:24:30 -0700 (PDT)
Received: from viefep16-int.chello.at (viefep16-int.chello.at [62.179.121.36]) by core3.amsl.com (Postfix) with ESMTP id 2148A3A6C1E for <ogpx@ietf.org>; Sun, 30 Aug 2009 16:22:55 -0700 (PDT)
Received: from edge03.upc.biz ([192.168.13.238]) by viefep16-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090830232304.SMJR9540.viefep16-int.chello.at@edge03.upc.biz>; Mon, 31 Aug 2009 01:23:04 +0200
Received: from mail9.alinoe.com ([77.250.43.12]) by edge03.upc.biz with edge id anP21c00U0FlQed03nP3Wb; Mon, 31 Aug 2009 01:23:04 +0200
X-SourceIP: 77.250.43.12
Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from <carlo@alinoe.com>) id 1Mhtku-0007OH-Df; Mon, 31 Aug 2009 01:24:16 +0200
Date: Mon, 31 Aug 2009 01:24:16 +0200
From: Carlo Wood <carlo@alinoe.com>
To: Meadhbh Siobhan <meadhbh.siobhan@gmail.com>
Message-ID: <20090830232416.GC25364@alinoe.com>
References: <b8ef0a220908291754x31f24ea7x702100d6aa9810ef@mail.gmail.com> <e0b04bba0908300225l34ec9f35x465d46f34313b60c@mail.gmail.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <4A9A9D5A.9020400@dcrocker.net> <382d73da0908301120n7e93d13j5b96151844df9a84@mail.gmail.com> <b8ef0a220908301150j61dd65d2pdbfe55416771595c@mail.gmail.com> <382d73da0908301158y5276835bt9e68ee91c6dae003@mail.gmail.com> <b8ef0a220908301248w18c136c1h6498195e9081b985@mail.gmail.com> <382d73da0908301309s23e6636fqb59bd75f3e1d5c1b@mail.gmail.com> <b8ef0a220908301500u72153ce6rbcb1e7767a826c7b@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <b8ef0a220908301500u72153ce6rbcb1e7767a826c7b@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: ogpx@ietf.org
Subject: Re: [ogpx] one virtual world, or many?
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Worlds and the Open Grid Protocol <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Aug 2009 23:24:30 -0000

On Sun, Aug 30, 2009 at 03:00:39PM -0700, Meadhbh Siobhan wrote:
> •	The Virtual World exists independent of the participating clients.
> •	Avatars have a single, unique presence in the virtual world.
> •	The virtual world contains persistent objects.
> •	The virtual world may be partitioned.
> •	Presence, state and simulation is managed on authoritative servers.
> •	Version skew between simulation hosts be tolerable.
> •	The protocol to access the state of hosts participating in the
> virtual world simulation uses Representational State Transfer (REST)
> style interaction over HTTP.
> •	A persistent, ubiquitous identity accompanies requests between hosts
> involved in the virtual world simulation.

Since there is no consensus about the meaning of "virtual world",
this list is pretty meaningless.

Imho, you mean to say that

•	Each 'E' exists independent of the participating clients.
•	Avatars have a single, unique presence in a given 'D'.
•	Each 'C' contains persistent objects.
•	Each 'C' may be partitioned.
•	Presence, state and simulation is managed on authoritative servers.
•	Version skew between 'A' hosts be tolerable.
•	The protocol to access the state of hosts participating in
'A' simulation uses Representational State Transfer (REST)
style interaction over HTTP.
•	A persistent, ubiquitous identity accompanies requests between hosts
involved in the 'E' simulation.

Where I defined 'A', 'C', 'D' and 'E' in my previous post.

-- 
Carlo Wood <carlo@alinoe.com>