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

Dzonatas Sol <dzonatas@gmail.com> Tue, 05 April 2011 22:08 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 976EF3A67EB for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 15:08:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.517
X-Spam-Level:
X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 sXRlfaFcncj7 for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 15:08:36 -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 0AB463A67D2 for <vwrap@ietf.org>; Tue, 5 Apr 2011 15:08:35 -0700 (PDT)
Received: by iwn39 with SMTP id 39so1024506iwn.31 for <vwrap@ietf.org>; Tue, 05 Apr 2011 15:10:19 -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=DOA1zjIJgTBQNRI2pZfKTLkDq19d2GdKIDdcDGmjXU4=; b=HgDHq33lkjCwgwJMCpn2rTjOkC4LOKvmwlWYE4oIwY2x0SReP3arArvO9nfIMMqP4i Cnd04JugXL7Vn3KSMxGUsvVy8sy59go7Ub5QgUJ+f09SAyTXZDoHf55qvbFtFRr3byM+ BrgwrieoJpDzrimXF/WnQwv7As1DX27Fdl65k=
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=v6HGQ8C+Kq4ru2L4Y3Wd8FG4haFzDXK2pbWFcLhATF/Ek/4rqW8lT9ahs1gZe1ApRy Gv2sDO62toDuwdnZkVAqjjErYGUpLIvvrrVWhYi3Pw0NBc4UCHtqhMhTAXuDOw2gM6p0 JNPp4oC8hWnSwaOnWhVZVoHN1RMFaOytx1TUs=
Received: by 10.231.141.20 with SMTP id k20mr195984ibu.132.1302041419275; Tue, 05 Apr 2011 15:10:19 -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 mv26sm4729761ibb.62.2011.04.05.15.10.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 15:10:18 -0700 (PDT)
Message-ID: <4D9B937C.1040403@gmail.com>
Date: Tue, 05 Apr 2011 15:11:08 -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>
In-Reply-To: <BANLkTimgdU6mzu+Vz-yUU_33cm9VrdHR0w@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:08:37 -0000

I don't see any description of LLIDL or anything trivially like it being 
described or based on documents now provided on the ietf vwrap wiki. 
Therefore, documentation incomplete. Moot point.

Local cache is still internal design, so what happen internally for 
cache optimizations does not mean all other aspect of the network are 
"the best design" by default. Again, correct functionality first. Local 
cache is not part of vwrap.

Digest URIs seem similar to the combined resources I already implemented 
and used even a year before you wrote that. Despite that, it seems like 
the age old IHAVE/SENDME protocols you can find RFCs dated before the 
late 80s. IHAVE/SENDME just didn't have to deal with public resource 
(combinable), as I have implemented: 
http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375

Your approach, besides exploitations, has the typical problem to assume 
asset IDs are only needed and are hash-able. I don't think you 
comprehend the moot point here, and thus probably have an agenda. 
(whatever it is... the ridicule and mockery make it apparent)

I think what you really want is the same thing I described with 
asset-"manafacturing", universal identifiers in URIs. Simple, it looks 
like "UUID:UUID", like any basic public key.

Documentation...?

Morgaine wrote:
> 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 
> <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>>> 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>>>> 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>>
>
>                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