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

Morgaine <morgaine.dinova@googlemail.com> Tue, 05 April 2011 21:20 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 AC7CB3A67D8 for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 14:20:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.792
X-Spam-Level:
X-Spam-Status: No, score=-2.792 tagged_above=-999 required=5 tests=[AWL=0.184, 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 n2XDOnqQ+ILq for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 14:20:08 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id B6BE43A67C1 for <vwrap@ietf.org>; Tue, 5 Apr 2011 14:20:08 -0700 (PDT)
Received: by pzk30 with SMTP id 30so387294pzk.31 for <vwrap@ietf.org>; Tue, 05 Apr 2011 14:21:52 -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=q+awjxTadWjHHIeRpJdEYg3jrY7Ahvlu/IpS2CYwU0w=; b=JUPeyNaDLoJcC5VMXWg+TjFjFGNnP2U8KsWK4wCIZar5tmURKhWc+puF+UlMnSzWuD SmSqKG8r1qcw/Yj9LOh+pXmMV18dfrMqLyR8pXAC3PAncsV2kF46DYiUdmqyfcAmsLYH zySPff855Io1wiHrM+Rex3aD4pjLpvO0JZOB8=
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=EbJd7KvbFfmDoKuo1RqGwxQZhNAhXwJIFOMqqnRPfcTjDFC3c5MIcMCtMT1QGBccbc AniWNKeSxLlwEySs4+zZCJEZZovBAiD0kWKJ9TKyu+fdfAnVYHlKlHKbXS1BOfwCLZrZ kqUUDvHyFKwQgvFRJKX3UZfqSaCVG5S+N5RIY=
MIME-Version: 1.0
Received: by 10.142.196.12 with SMTP id t12mr119443wff.449.1302038512056; Tue, 05 Apr 2011 14:21:52 -0700 (PDT)
Received: by 10.142.246.6 with HTTP; Tue, 5 Apr 2011 14:21:51 -0700 (PDT)
In-Reply-To: <4D9B73D5.4000809@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> <BANLkTi=hX1ne=hvFqPh_EwTV_Urryxbp_A@mail.gmail.com> <4D9B73D5.4000809@gmail.com>
Date: Tue, 05 Apr 2011 22:21:51 +0100
Message-ID: <BANLkTikO5qY+ZOJuMkBfMRT2Y3HjtPCLYw@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: vwrap@ietf.org
Content-Type: multipart/alternative; boundary="000e0cd2e1ecfeb99b04a03276b3"
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 21:20:10 -0000

Unfortunately your response was devoid of technical content, Dzonatas.

If you have something technical to say about hash-based addressing, I would
love to hear it.

I have detailed in some depth the many benefits of hash-based addressing in
the article I linked, and subsequently.  If other good schemes exist, we
should of course analyze them for technical merit and compare their benefits
against those of hash-based addressing.

That's the engineering process for making VWRAP as good as it can be.


Morgaine.




=========================

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

> Morgaine, we mooted your hash-based idea. This does nothing to help
> implement asset services. The only significant point you made is some
> expression for optimization, not correct functionality, which is needed
> first
>
> As for your other two, we can summarize those with public resources and
> flow (forward/reverse). Any more specific network topology than that only
> makes it harder to address. The only thing to worry about is already custom
> resources that overlap with newer public resources.
>
> Morgaine wrote:
>
>> On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol <dzonatas@gmail.com <mailto:
>> 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.
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> vwrap mailing list
>> vwrap@ietf.org
>> https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>
>
> --
> --- https://twitter.com/Dzonatas_Sol ---
> Web Development, Software Engineering, Virtual Reality, Consultant
>
>