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

Izzy Alanis <izzyalanis@gmail.com> Thu, 07 April 2011 03:29 UTC

Return-Path: <izzyalanis@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 2D5563A6978 for <vwrap@core3.amsl.com>; Wed, 6 Apr 2011 20:29:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.257
X-Spam-Level:
X-Spam-Status: No, score=-1.257 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666]
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 32ESCq06iqVa for <vwrap@core3.amsl.com>; Wed, 6 Apr 2011 20:29:17 -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 196733A6809 for <vwrap@ietf.org>; Wed, 6 Apr 2011 20:29:17 -0700 (PDT)
Received: by qyk7 with SMTP id 7so1379045qyk.10 for <vwrap@ietf.org>; Wed, 06 Apr 2011 20:31:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-type:message-id:content-transfer-encoding:cc:x-mailer:from :subject:date:to; bh=2Q6/e6Kr/JVbcVLBDnSe/2P0mTOYYTGpFGUdxYz7IDQ=; b=dmWF5C7tcobx8gR+IrJenHpIxmEZXgfLSrYs92Tpgsu6KeULAQoeGaZU5JuN+sKPXB QfdE/GptMc/0iWSWfNhNk6N+JgqjBprTS4gg/P6uXaPLh52PTr5cznIW7sEe7xSd/09z muKLSEg/LIvO5DkjP0rCGtz5QGrJku6k7VBQ8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; b=V1yJ4jy3SiSzeutvJgNwETwGu7Y8sx/LlUQVZvU8whOgeQLyWC9iFGQEh97ow6d9TP 5BMHpeg5jJLnvrbaXPqSFWfT/bhlbw1AadM9STiUs7W6lRq6t9i+DUfPXpOItMv7wmxS Nb3xCJA23FpMHETzLffdsewV0hx+6mkhit/PY=
Received: by 10.224.210.67 with SMTP id gj3mr272255qab.28.1302147060705; Wed, 06 Apr 2011 20:31:00 -0700 (PDT)
Received: from [192.168.1.108] (c-75-68-52-200.hsd1.nh.comcast.net [75.68.52.200]) by mx.google.com with ESMTPS id f5sm886786qck.20.2011.04.06.20.30.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 20:30:58 -0700 (PDT)
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> <BANLkTi=zpAKKDzGiiNLG_Q=SDCgrS0t48w@mail.gmail.com> <4D9BB342.7020607@gmail.com> <BANLkTimGZniPfHvmyOyf3UO+DrRcqYMCsQ@mail.gmail.com> <BANLkTimzL8cZ8_riviMeUQtodfAwf-ekiw@mail.gmail.com>
In-Reply-To: <BANLkTimzL8cZ8_riviMeUQtodfAwf-ekiw@mail.gmail.com>
Mime-Version: 1.0 (iPad Mail 8C148)
Content-Type: multipart/alternative; boundary=Apple-Mail-1--430177921
Message-Id: <B4FD985C-B92A-4827-9923-ADA02017470E@gmail.com>
Content-Transfer-Encoding: 7bit
X-Mailer: iPad Mail (8C148)
From: Izzy Alanis <izzyalanis@gmail.com>
Date: Wed, 6 Apr 2011 23:30:47 -0400
To: Morgaine <morgaine.dinova@googlemail.com>
Cc: "vwrap@ietf.org" <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: Thu, 07 Apr 2011 03:29:22 -0000

Yes, yes, yes... The question was more about how you want those ideas reflected in the documents.

- Izzy

On Apr 5, 2011, at 10:12 PM, Morgaine <morgaine.dinova@googlemail.com> wrote:

> I'm not sure at what stage you joined us Izzy, but support for flexibility and extensibility in the protocol has been preached by us regularly throughout the entire lifetime of the MMOX, OGPX and now VWRAP groups, so it's nothing new, really.  It could be said to have been lip service before though, seeing as no new features ever materialized from it.
> 
> The only significant difference now is that Carlo has tried to turn that lip service into an agreed process for promoting proposals that are aimed at providing extra flexibility and extensibility.  The fact that this idea hasn't received much support is a bit worrying.
> 
> It wouldn't matter at all if the group was by its nature strongly focused on creating a protocol "designed for the future", eagerly selecting the ideas with the best outlook for a massively scaled and buoyant metaverse, a protocol that recognizes that virtual worlds will evolve rapidly once they gain synergy from interoperation.  Indeed, Carlo's a priori agreement would then be entirely superfluous.  But instead of eagerly welcoming forward-looking proposals with excellent engineering merits, the few we've had so far seem to be greeted with intense resistance and avoidance of technical discussion.  It's an uphill struggle.
> 
> I can see why Carlo was so highly despondent in his last post.  Conditions aren't too encouraging at the moment for an advanced, extensible protocol.
> 
> And perhaps there is no solution.  You can't make a horse drink, even when there is plenty of water provided.
> 
> 
> Morgaine.
> 
> 
> 
> 
> 
> =======================
> 
> On Wed, Apr 6, 2011 at 2:24 AM, Izzy Alanis <izzyalanis@gmail.com> wrote:
> Along the lines of documentation... are we salvaging the last draft
> intro doc or scrapping it? If we're scrapping it, what about it didn't
> we like, what about it was good? The work on shoring up definitions is
> directly applicable to the intro doc, but the minute details of asset
> addressability and cacheability are leading us down a rat hole -- it's
> interesting conversation, but just not productive right now.
> 
> Toward Carlo's mission of 'flexibility first': how would a statement
> about the flexibility of the protocol appear in such a document?
> 
> - Izzy
> 
> 
> On Tue, Apr 5, 2011 at 8:26 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
> > We were and still are in discussion about VWRAP documents.
> >
> > As someone that implements, they don't want to read anything like "many
> > orders of magnitude" or "the best idea" or such exaggerated adjectives.
> > Don't expect your ideas ever to get implemented based on such language.
> >
> > Need just the facts, and the documents. Please, stop with how great you
> > think your idea is and produce the documents! Please include specific use of
> > the resources, LLIDL, DSD, etc.
> >
> > If this continues to be just discussion and neither documentation nor
> > implementation than I'm with the chair(s) to disband.
> >
> > Morgaine wrote:
> >>
> >> 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
> >> <mailto: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 <mailto:dzonatas@gmail.com>
> >>        <mailto: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>>
> >>               <mailto: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>>>
> >>                      <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:
> >>
> >>                         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>>>>
> >>                             <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 <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>>>
> >>                      <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 <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>>
> >>               <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
> >
> > _______________________________________________
> > vwrap mailing list
> > vwrap@ietf.org
> > https://www.ietf.org/mailman/listinfo/vwrap
> >
> 
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap