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

Morgaine <morgaine.dinova@googlemail.com> Tue, 05 April 2011 18:54 UTC

Return-Path: <morgaine.dinova@googlemail.com>
X-Original-To: vwrap@core3.amsl.com
Delivered-To: vwrap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFCF73A6974 for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 11:54:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 eHnc+JnPLfUu for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 11:54:39 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 2CA0C3A6359 for <vwrap@ietf.org>; Tue, 5 Apr 2011 11:54:39 -0700 (PDT)
Received: by pvh1 with SMTP id 1so329425pvh.31 for <vwrap@ietf.org>; Tue, 05 Apr 2011 11:56:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=7xPmh8tHQaUpyb8+6Q5WnEzISfZPPBAL7fg3KyNiUiU=; b=LUQWTbau3J5ANcTbNieLIwN2ZSrvrTDyvVODKyCSVqS7ztKZgsTxDBeTJoWO7DzdY0 5t33OJyc9req2XeVZ/g4aAYD4lCMuHZEAyaT1o9iVXNiAisOretN4vXy0351r/blpc6H Vm31L1t6B4ARAPO7+9hdSEoK9l37eZd50Gk6o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=uvX5YyhofEkq2gq7+osq9lvfUnQyqW4Vw45HLvScEa7MoMQmCZRACQRAQbSxIr7LsH UOeUBzlU7Xn8WdJsviBf3CM9lKO5y21xoA9a7IxmzRbf8INIfGeCVcKBODCpC9qMzIb5 kvk7asKgKfAerO6PMuWsBxeSh2vbr1yr3wcHE=
MIME-Version: 1.0
Received: by 10.142.122.40 with SMTP id u40mr12515wfc.335.1302029782162; Tue, 05 Apr 2011 11:56:22 -0700 (PDT)
Received: by 10.142.246.6 with HTTP; Tue, 5 Apr 2011 11:56:21 -0700 (PDT)
In-Reply-To: <4D9B4586.9080004@gmail.com>
References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <AANLkTimcMbrJzXYTvs0cszn+rhH4ygEPvzvLwu94gr-4@mail.gmail.com> <BANLkTi=hL5YTAW9_V7EA3C3fiknU0o_ARA@mail.gmail.com> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com>
Date: Tue, 05 Apr 2011 19:56:21 +0100
Message-ID: <BANLkTi=hX1ne=hvFqPh_EwTV_Urryxbp_A@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: vwrap@ietf.org
Content-Type: multipart/alternative; boundary="001636e1f7e1a71e9904a0306ee4"
Subject: Re: [vwrap] Statements of Consensus. Flexibity First.
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 18:54:43 -0000

On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:

>
> Do you think we are ready to implement some asset services now,
> with/without complete documentation?
>
> What more do you think is needed?
>
>
> Two or three things seem to be needed:


   - Defining the asset addressing concept is an extremely important matter,
   almost certainly the most important matter of all, because that determines
   how robust and scalable our worlds will be.  I've already examined
   alternatives for that in some depth, and the design with the best
   engineering properties so far seems to be universal hash-based addressing.
   I first described that approach on the list here ---
   http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html , and
   referred to it in various subsequent discussions.


   - Defining the data flows between regions, clients, and asset services
   and which parameters control the flows needs to be done before a test asset
   service can be implemented.  Without that, an asset service is just a
   network-accessible storage service, not an asset service in the VWRAP
   sense.  Network storage services exist already, so just implementing one of
   those would not advance VWRAP.


   - We need to examine how various deployment patterns will use the asset
   services, and how the *multiple* asset services that interop introduces
   are handled.  I am working on this currently.


None of the above is particularly hard.  I think it won't be long before we
have a scheme worked out and are ready for some implementation work.


Morgaine.