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

[Morgaine <[e-mail]>]

*"Facts and documents*":  Link already provided.  Hash-based asset
addressing is just one protocol design element out of many hundreds in
VWRAP, and it would appear as a small technical detail in a future VWRAP
document, not a VWRAP document in its own right.

"*Many orders of magnitude*":  Performance Gain = (time to fetch an asset
over the network) / (time to fetch an asset from client cache with no
network access required) .  This could easily be 5 orders of magnitude under
normal operation, and a lot more under conditions of service congestion.


Morgaine.



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

On Wed, Apr 6, 2011 at 1:26 AM, Dzonatas Sol <[e-mail]> 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 <[e-mail]<mailto:
>> [e-mail]>> 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
>>        <[e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>> 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
>>               <[e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>
>>               <mailto:[e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>>> 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
>>                      <[e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>
>>               <mailto:[e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>>
>>                      <mailto:[e-mail]
>>        <mailto:[e-mail]> <mailto:[e-mail]
>>        <mailto:[e-mail]>>
>>               <mailto:[e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>>>> 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
>>                             <[e-mail]
>>        <mailto:[e-mail]> <mailto:[e-mail]
>>        <mailto:[e-mail]>>
>>               <mailto:[e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>>
>>                      <mailto:[e-mail]
>>        <mailto:[e-mail]> <mailto:[e-mail]
>>        <mailto:[e-mail]>>
>>               <mailto:[e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>>>
>>                             <mailto:[e-mail]
>>        <mailto:[e-mail]>
>>               <mailto:[e-mail] <mailto:[e-mail]>>
>>        <mailto:[e-mail] <mailto:[e-mail]>
>>               <mailto:[e-mail] <mailto:[e-mail]>>>
>>                      <mailto:[e-mail]
>>        <mailto:[e-mail]> <mailto:[e-mail]
>>        <mailto:[e-mail]>>
>>               <mailto:[e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>>>>> 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
>>                             [e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>
>>               <mailto:[e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>>
>>                      <mailto:[e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>
>>               <mailto:[e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>>>
>>
>>
>>                             https://www.ietf.org/mailman/listinfo/vwrap
>>                                                    --     ---
>> https://twitter.com/Dzonatas_Sol ---
>>                         Web Development, Software Engineering,
>>        Virtual Reality,
>>                      Consultant
>>
>>
>>
>>  ------------------------------------------------------------------------
>>
>>                      _______________________________________________
>>                      vwrap mailing list
>>                      [e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>
>>               <mailto:[e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>>
>>                      https://www.ietf.org/mailman/listinfo/vwrap
>>
>>                  --     --- https://twitter.com/Dzonatas_Sol ---
>>                  Web Development, Software Engineering, Virtual Reality,
>>               Consultant
>>
>>
>>
>>  ------------------------------------------------------------------------
>>
>>               _______________________________________________
>>               vwrap mailing list
>>               [e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>
>>               https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>>           --     --- https://twitter.com/Dzonatas_Sol ---
>>           Web Development, Software Engineering, Virtual Reality,
>>        Consultant
>>
>>
>>
>>  ------------------------------------------------------------------------
>>
>>        _______________________________________________
>>        vwrap mailing list
>>        [e-mail] <mailto:[e-mail]>
>>        https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>>
>>    --     --- https://twitter.com/Dzonatas_Sol ---
>>    Web Development, Software Engineering, Virtual Reality, Consultant
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> vwrap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>
>
> --
> --- https://twitter.com/Dzonatas_Sol ---
> Web Development, Software Engineering, Virtual Reality, Consultant
>
>