Re: [vwrap] [wvrap] Simulation consistency

[Dzonatas Sol <[e-mail]>]

Again, you assumed too much and narrowed it down too some straw-man 
argument of UUID only. There are many ways to cache.

SNOW-375 has the functionality for hash-based, if you want to further 
the public/private implementation of URIs. The functionality for 
private-URI being based on public URIs (as documented) is just cache and 
redirect, not much different from hash-based as you describe. I just 
haven't implemented login option create a digest for private URIs (as 
noted in the documentation section about "feature freeze"). Purposely 
waited...   (and I'm in 
multi-point/multi-client/full-duplex/anti-exploit mindset )...

...and waited...

Despite my reasons to wait and do other things, open virtual worlds vs 
legacy...

I'll lean more towards organic and analog based types then identical 
assets, especially if virtual worlds include real world peripherals.


Morgaine wrote:
> Hash-based addressing is very different to UUID-based addressing as 
> used in SNOW-375, so I expect there is some misunderstanding of how 
> hash digests are applied in this scheme,
>
> The universal address of the item is the hash digest over the data of 
> the item using a specified digest algorithm, and is not a UUID.  It is 
> invariant regardless of who computes it, although it would normally be 
> computed only once by the asset service at the time that the item is 
> being stored in the service.  All asset services everywhere will use 
> the same digest as an address for this item, because the digest 
> algorithm is specified.
>
> Data that is addressed and indexed in this way can of course be used 
> in a REST architecture with appropriate design, but because hash 
> digests are not UUIDs, there is quite a different semantic to it.  A 
> UUID cannot be used as a shared cache index in a multi-world 
> architecture, because identical content in N different worlds will 
> have different UUIDs associated with it in each world.  In contrast, 
> identical content in N different worlds will have an identical hash in 
> every world, and therefore only a single storage entry is needed in a 
> multi-world cache.
>
> The effect of this is dramatic.  Every time that an Object ARchive is 
> loaded to populate a new region, this can generate another several 
> hundred thousand (and soon, millions) of new assets which in a 
> UUID-addressed scheme will typically just grow the asset storage 
> without bound.  In a hash-addressed scheme, that OAR can be loaded a 
> million times and the asset data storage doesn't increase by 1 byte, 
> neither in the asset server, the region, nor in client caches.  Only 
> metadata storage need grow for repeated assets in asset services, but 
> it's not even needed in client-side caches, so the benefits are huge.
>
> A nice mental image that really brings this home is that of grass 
> patches and trees and other common environmental objects reused in 
> countless worlds across the metaverse, yet requiring no downloads at 
> all as you tour around the worlds because visiting just one world has 
> populated your persistent cache with those common items already.
>
> This can represents storage savings of thousands or even millions to 
> 1, and corresponding time savings too because the remote fetches from 
> asset services are avoided entirely.  The impact of this scheme on 
> user experience can be expected to be outstanding even in today's 
> humble beginnings, and much more so as the metaverse blooms.  It's the 
> scheme with the best performance and scalability of any we have 
> examined so far.
>
> UUID-based asset storage does not have these excellent properties, nor 
> the other advantages that I have described previously.
>
>
> Morgaine.
>
>
>
>
>
> =====================
>
> On Sat, Apr 2, 2011 at 4:36 PM, Dzonatas Sol <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Your hash/digest method is similar to basic REST and what I
>     already implemented. Icesphere already has implementations and
>     methods and even furthers them with burst modes so where there is
>     no worry to have a URI for each asset. The URI can specify a list
>     of assets or single asset (content varies as such), which can be
>     returned immediately or when each is ready for transfer,
>     individually. Uses LLIDL with proposed changes:
>
>     Everything is documented here:
>     http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Inventory
>     (Last edited that doc in August 2010 & Icesphere's implementation
>     has been used for awhile since then)
>
>
>
>     Morgaine wrote:
>
>         Back in September 2010, I wrote this post which proposes that
>         we use in VWRAP a form of asset addressing that provides
>         massive scalability at the same time as a very high degree of
>         resilience --
>         http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html
>         .� It is based on the concept of the URI containing a host
>         part and a hash part, where the hash is generated (once, at
>         the time of storage to the asset service) using a specified
>         digest algorithm over the content of the asset being
>         referenced.� You may wish to note that if this design were
>         used, the failure of an asset service to deliver a requested
>         item would result in a failover request for the item to one or
>         more backup services, using the same hash part but with a
>         different host address.
>
>
>
>     -- 
>     --- 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