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

Morgaine <morgaine.dinova@googlemail.com> Wed, 06 April 2011 00:02 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 ADDFF3A6846 for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 17:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.506
X-Spam-Level:
X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, 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 W6IlaORm4RUJ for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 17:02:38 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 42DBD3A6844 for <vwrap@ietf.org>; Tue, 5 Apr 2011 17:02:38 -0700 (PDT)
Received: by qwc23 with SMTP id 23so676559qwc.31 for <vwrap@ietf.org>; Tue, 05 Apr 2011 17:04:21 -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=lk8VABYZtUqM8owNK+HOdNicn/6tk+oNofMmr1YMWws=; b=E9aS3+EH6NDHpt2hSg2hgGLZbamqcyUhon1F3k8jmDB2zV41L8n43Ts7HKZZGD31tp LFT0HoHIHbSJfJzkuq17Hj1awC94fMlCy5djc+p7t1/thr3ylk3UQ9kaahwxQU7cJyPA Ab7fFGCPwVX563Mbg533BcT/gGHbWFdau5qM0=
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=c9lBB6cLtxWfrP7siZwShhCpLXzhrUVgF8/2tRJ1sGIRMcZxucyoGoOgACpAgCyeWj 0WmNWgkVwmZJS9ipRsvRO2Y7iozOP+rgKCB16hg3HISKJzVXstr0ceyY2oFWPmZmJBYH eTqDdcsBWDzy4z+vqoc00aw6YfhDkDd+d0X1M=
MIME-Version: 1.0
Received: by 10.229.37.130 with SMTP id x2mr250931qcd.147.1302048261257; Tue, 05 Apr 2011 17:04:21 -0700 (PDT)
Received: by 10.229.211.84 with HTTP; Tue, 5 Apr 2011 17:04:20 -0700 (PDT)
In-Reply-To: <4D9B9D4A.7050006@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> <BANLkTimgdU6mzu+Vz-yUU_33cm9VrdHR0w@mail.gmail.com> <4D9B937C.1040403@gmail.com> <BANLkTik+V6xfbrx07eQO-zNq9r1v03j6CQ@mail.gmail.com> <4D9B9D4A.7050006@gmail.com>
Date: Wed, 6 Apr 2011 01:04:20 +0100
Message-ID: <BANLkTi=zpAKKDzGiiNLG_Q=SDCgrS0t48w@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: vwrap@ietf.org
Content-Type: multipart/alternative; boundary=0016368340c017b90204a034bc95
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: Wed, 06 Apr 2011 00:02:41 -0000

The asset fetch performance gain of a protocol in which asset identifiers
make cross-world assets cacheable versus a protocol whose asset identifiers
do not allow this is an extremely large factor of *many orders of
magnitude*on all but the first occurrence of an asset.  For all
intents and purposes,
avoiding the need to fetch an asset over the network represents a gain of
infinity, and this gain may be repeated many times over.

I think it's pretty uncontestable that giving VWRAP an asset addressing
scheme which is orders of magnitude more efficient than any other scheme
that has yet been proposed would be an important benefit for the protocol,
and highly likely to make it popular.  Conversely, if it lacks this benefit
then another protocol will use it and will hugely out-perform VWRAP.

We were talking about designing for the future.  Hash-based asset addressing
is a case in point, and how we handle this proposal is apparently our first
test case.


Morgaine.





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


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

> And... still local cache.. not vwrap.
>
> I think it would be more wise to go with the implementations of Google's
> and/or Siemens object identification to RFID codes. At least we know this
> part won't exploit content.
>
> It has further advantages than just that. I went into detail awhile ago,
> yet with basic QM:
> http://icyspherical.blogspot.com/2010/07/optimizing-simulations-with-basic.html
>
> No, even given the possibilities presented, I don't think your idea comes
> close to anything new in regards to the best. It's just your preference.
>
> Morgaine wrote:
>
>> On Tue, Apr 5, 2011 at 11:11 PM, Dzonatas Sol <dzonatas@gmail.com<mailtomailto:
>> dzonatas@gmail.com>> wrote:
>>
>>
>>    Your approach, besides exploitations, has the typical problem to
>>    assume asset IDs are only needed and are hash-able.
>>
>>
>>
>> Asset IDs are not hash-able, it is the asset data that is hashed.  The
>> asset identifier is the hash of the asset data using a defined hash digest
>> algorithm.  The asset identifier is not guessable unless you already have
>> access to the asset.
>>
>>
>> Morgaine.
>>
>>
>>
>>
>> =============================
>>
>>
>>
>>        ==================
>>
>>        On Tue, Apr 5, 2011 at 10:34 PM, Dzonatas Sol
>>        <dzonatas@gmail.com <mailto:dzonatas@gmail.com>
>>        <mailto:dzonatas@gmail.com <mailto: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>
>>        <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>
>>               <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>
>>        <mailto: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>>
>>               <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>
>>        <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>
>>                      <mailto:dzonatas@gmail.com
>>        <mailto:dzonatas@gmail.com> <mailto:dzonatas@gmail.com
>>        <mailto:dzonatas@gmail.com>>
>>               <mailto: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>
>>        <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>>
>>               <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>
>>        <mailto: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 <mailto:vwrap@ietf.org>
>>        <mailto: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 <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
>
>