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

Dzonatas Sol <dzonatas@gmail.com> Tue, 05 April 2011 22:50 UTC

Return-Path: <dzonatas@gmail.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 C300A28C163 for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 15:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.518
X-Spam-Level:
X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, 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 JDp+wUZeozxu for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 15:50:27 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 0803928C162 for <vwrap@ietf.org>; Tue, 5 Apr 2011 15:50:26 -0700 (PDT)
Received: by iwn39 with SMTP id 39so1059835iwn.31 for <vwrap@ietf.org>; Tue, 05 Apr 2011 15:52:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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=cGaJpCUbnbaJT6AMaFno7aEGNNlcDmT/RBDFIntq9qM=; b=xiHTP7wrLqzMmtdoF52KqHYqdifU+B3/OyN1pEu1Vp1MC7xJ+iNVm3lCFf8oU3jmRR 3IT9XJsulE/QEQemy/WuXVjTjjM9y8I/AVAm9jE5iphLalcchs8tcKKhowukqURmwfsd +WevT9Jk1OWQmUEMv8h3B0nj93dAPlLnMCz6A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=YpbiKCn33E2x5Tp4QGuwqql6dqVoBDWMT83KaTaK4q7jqgnL0Ma+ei0LPo5WEhWAjB OevPi9T+0Axp8kJb3QRddowagI/bOUCkPQIBmTcNjItH+EP/6br9IM00zg2S5C2PDl/w TuDUE3CXZUvEmbMEj1PRuRRqwdOoEtpua0vg8=
Received: by 10.43.69.202 with SMTP id yd10mr371492icb.375.1302043930340; Tue, 05 Apr 2011 15:52:10 -0700 (PDT)
Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id wu1sm4439016icb.22.2011.04.05.15.52.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 15:52:09 -0700 (PDT)
Message-ID: <4D9B9D4A.7050006@gmail.com>
Date: Tue, 05 Apr 2011 15:52:58 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329)
MIME-Version: 1.0
To: Morgaine <morgaine.dinova@googlemail.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>
In-Reply-To: <BANLkTik+V6xfbrx07eQO-zNq9r1v03j6CQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: vwrap@ietf.org
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 22:50:28 -0000

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 
> <mailto: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