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

Morgaine <morgaine.dinova@googlemail.com> Tue, 05 April 2011 21:46 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 17A5F28C113 for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 14:46:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level:
X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[AWL=0.180, 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 msznGRPVtOjh for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 14:46:51 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 1F33628C105 for <vwrap@ietf.org>; Tue, 5 Apr 2011 14:46:51 -0700 (PDT)
Received: by qyk7 with SMTP id 7so560295qyk.10 for <vwrap@ietf.org>; Tue, 05 Apr 2011 14:48:34 -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=15ln1yBmo15L2mhRtG6xU+g37IX5UxNNJNXPJkm/uOQ=; b=rHIlVARMuC6FxwBVvwTEQJ4kSM3mdjfeLIT7Kz/FhE3MZPmKDwJIGO9+oXunHLPA52 Pn7D3O9XkjUFWbXhLFU6XGPPYS7aeUbXn0RTS9gj+TLMJHL9jBgjrWbUfiLMRGG8sQvM Ef95SioTwl7DfIb/9l/myfkO6d2M7bA2vVr1s=
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=baKkl39v4qyaHTJtfjGFKFSVI4YuRJF+qr0+Ums4Z5X0CqSI/O1yme8Dcw7aKr0cXY 0coA6CMjd6hgoVMsMtwxRTGh70uP2WYHAtfUfOmwG3ikWtM3c1nnhuwcP81XSoKIYH/y a8ebDzBKom2ORTdo7kcgdKf/50d2SQ+ry57Wg=
MIME-Version: 1.0
Received: by 10.229.37.130 with SMTP id x2mr181275qcd.147.1302040113130; Tue, 05 Apr 2011 14:48:33 -0700 (PDT)
Received: by 10.229.211.84 with HTTP; Tue, 5 Apr 2011 14:48:32 -0700 (PDT)
In-Reply-To: <4D9B8ADA.9000106@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> <BANLkTikO5qY+ZOJuMkBfMRT2Y3HjtPCLYw@mail.gmail.com> <4D9B8ADA.9000106@gmail.com>
Date: Tue, 5 Apr 2011 22:48:32 +0100
Message-ID: <BANLkTimgdU6mzu+Vz-yUU_33cm9VrdHR0w@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: vwrap@ietf.org
Content-Type: multipart/alternative; boundary=0016368340c06d2d9b04a032d6fc
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:46:53 -0000

How hash-based addressing works and is how the addresses are structured and
used in URIs is fully specified in my first article, Dzonatas.

The only element of the design not specified is *WHICH* particular hash
digest algorithm is employed, since the choice is not particularly
significant.  The merits of the design are attained regardless of the
particular digest chosen.  Because we are trying to achieve extensibility
for future proofing, a good approach would be to use an URI style that makes
choice of digest algorithm explicit.

As for implementations, a test implementation is already running in Mojito
Sorbet's experimental world and client, which are open source.

I welcome analysis of this addressing scheme, and of alternative addressing
schemes.  I haven't yet seen one with engineering properties that are
anywhere near as good as this, as I detailed in the article.  Hash-based
addressing sets the merit bar very high.


Morgaine.





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

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

> Again Morgaine, your appeals alone don't support themselves, and your
> ridicule is unwelcome. If you can not honestly make any serious response,
> please move on and don't reply to my posts just to further ridicule. It's
> very RUDE.
>
> If you have any implementation of your hash-based idea or actual technical
> detailed documentation ready for implementation, then introduce it. Until
> then, it's stuck in your head, and sounds other's ideas just with your name
> on it. Plus security by obscurity makes it as moot point.
>
> Documentation... ?
>
> Remember people tried to take one temp variable away from the JPEG2000 int
> multiple/divide routine because the idea it looks good (on paper) with one
> less variable. Actual implementation reveals, with timed tests, it is slower
> when anybody takes away that one temp variable.
>
> Morgaine wrote:
>
>> 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 <mailto:
>> 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>
>>        <mailto: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 <mailto:vwrap@ietf.org>
>>
>>        https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>>
>>    --     --- https://twitter.com/Dzonatas_Sol ---
>>    Web Development, Software Engineering, Virtual Reality, Consultant
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>
>