Re: [vwrap] Statements of Consensus. Flexibity First.

Dzonatas Sol <> Wed, 30 March 2011 18:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11B7628C195 for <>; Wed, 30 Mar 2011 11:22:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.508
X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xcp0YqW8Se3k for <>; Wed, 30 Mar 2011 11:22:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 936E33A6BB0 for <>; Wed, 30 Mar 2011 11:22:42 -0700 (PDT)
Received: by iwn39 with SMTP id 39so1746101iwn.31 for <>; Wed, 30 Mar 2011 11:24:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=acs20uUgmLqL2l1xud0dHRyfQBdf9xbUHfrKCsUY4bo=; b=kTIL15tNkA1qvZanPsrLxATisQdgyimNpoZdIX8cdtYiYauJwMyS7Ari9bF38000O7 b5fB3KER52bOcZqbcijsg1eSW0XTb6gPqby33aIuJerPG7PkMnH5oxnsAg2KzJRYan2c 7EBzLvn6gQ+O9NFbJ+brX8E8POpLJn+7uax7Q=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Sx0ThWxm4kno3czwsveD58j7CfUvi2fLmmX44mzYDLUKCHdPHddawtAGI3Z8ZBOAxU uFp9D07zDFVIgEXmal0jZLyoVocv8s34BEgUnOYftYNJZh6DZheuwmtPgtBrXnvPOzD8 mbb648nIkz/ZbFAo1KWbL9fw9o+xEQTnyuytM=
Received: by with SMTP id r5mr1454219icq.509.1301509461496; Wed, 30 Mar 2011 11:24:21 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id va4sm89041icb.15.2011. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 11:24:20 -0700 (PDT)
Message-ID: <>
Date: Wed, 30 Mar 2011 11:23:53 -0700
From: Dzonatas Sol <>
User-Agent: Mozilla-Thunderbird (X11/20100329)
MIME-Version: 1.0
To: Morgaine <>
References: <> <> <> <> <1301499645.12359.10.camel@mdickson-hplinux> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [vwrap] Statements of Consensus. Flexibity First.
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Mar 2011 18:22:44 -0000

Morgaine wrote:
> No Dzonatas, that's not enough to handle the requirement.
> When I TP from world X to world Y (which I may never have visited 
> before), my identity, avatar and clothing need to persist across the 
> teleport, and the elements that I carry with me (such as clothing) may 
> come from many different worlds which I have visited previously, and 
> be served from their individual asset services while I'm away touring 
> in world Y.

Of course, like I said, it is rough, so there is no need to assume that 
it will not be handled by even less optimal formats. That point being 
that even the COLLADA format has conditioners/refineries  that document 
how to do such above. The difference only being doing it LIVE and doing 
it through asset servers, which still are not separated from the region.

> What's more, visiting thousands of worlds and having to make accounts 
> at each of them is untenable, and will stop virtual worlds from 
> flourishing.� It creates a major stumbling block for user acceptance.
> What's needed cannot be accomplished with client-side trickery.� It 
> needs regions to understand multiple non-local asset services, and 
> portable avatars, and single sign on, and it needs many of the 
> protocols that we use in our region-proxied worlds to change, not only 
> to cater for this required flexibility, but also for scalability and 
> robustness in a distributed architecture which we've discussed here 
> before.

Please be sure to read up on COLLADA format and notice that it is a 
digital asset exchange format for doing much of the above. We just need 
to make sure we do not reinvent the wheel (its "rough").

I think what "client-side trickery" is the pretense that there will be 
no need for "manufactured" objects. You stated above, however, the 
"manufactured" case of which assets may come from different non-local 
areas. No need to spin this or make such assumption as you did. Please 
do your homework.

--- ---
Web Development, Software Engineering, Virtual Reality, Consultant