[Opensim-dev] Proposal to subdivide the assets table

[Stefan Andersson]

> Well, to make a long story short: Regions don't own assets. Regions > use assets. Users own assets.
I do know that you are primarily interested in the SL paradigm. 
 
But from where I'm coming, there's definitively scenarios where regions can own assets.
 
The question is whether those assets can then leave the region.
> So, a centralized asset storage is certainly needed, tied into the > concepts around asset portability, possibly several centralized > asset servers.
I don't think portable assets should be our base case.
> But assets are immutable and a region is a finite space. This makes > it an ideal situation for a persistent cache. 
 
Totally so.
 
> Tier 1: referenced assets, indefinite retention> Tier 2: unreferenced assets, short term retention
How would one decide what assets are 'referenced'?
 > However, because of the ability to reference an asset by it's UUID, > letting a region "own" an asset is still not possible.
Actually, there is still a 'calling context' around that reference.
 
Building from what I call the 'base case' you can definitively solve a lot of these references, one feature at a time.
 
(For example, if each avatar had a 'home asset server' that is supposed to serve the avatars assets, the case of resolving 'wearables' would mean going thru the wearables, requesting them from the home asset server, and caching them - possibly under a _local_ id. Of course, the next step would be resolving assets referenced by those wearables, but that's the next step.)
 
(A 'home asset server' could have a 'default gateway asset server' that it falls back upon if it can't find an asset. And again, permanently cache it if found 'upstreams'.)
> But, now there are three scenarios:> > 1) The prim is pushed across a region boundary. The destination > region requests the texture from the asset server and fails. The > prim will turn gray.
a) Provided the scenario allows pushing local prims across boundaries.
b) The Prim can have a 'home asset server' which is the first region.
> 2) The prim has previously been "take"n. A copy exists in egent > inventory, but the list of the resources needed to reconstitute this > "object" is hidden in the asset, actually, multiple asset records. > If the texture has been removed from the central server, rezzing > this object in any region where the texture is not in use will fail.
a) Provided the scenario allows local prims to be 'taken'
b) See 1, I guess?
> 3) If i deleted the texture, there is no guarantee that I have also > lost it's UUID. I may have a notecard with all my texture UUIDs and > use them in scripts. Such scripts, taken to other regions, would fail.
So, what happens if we let go of the paradigms of the online social game Second Life and think more of how the web works?
 
There is definitively a lot of 404's and broken image links out there. And somehow, it's still useable.
> Issue 1 could be addressed by transferring the needed resources > along with the object, however, on a distributed grid like OSGrid, > this can be time-consuming, as home DSL may be involved.
Maybe I misunderstand you, but in order to forward it to the agent, we need to transfer it to the region anyway.
> Issue 3 could be addressed by creating a list of resources needed at > the time of the "take" and making that part of the inventory record. > This would significantly bloat the inventory table, as each prim's > inventory, face textures and all sounds/animations it might play are > listed in the database.> > Issue 3 cannot be reasonably addressed.
I beg to differ. I think this very doable. I just think we need to boil the use case down.
> Therefore, caching, which is something I have looked into and am > going to write some code for, is an absolutely viable solution for > many of the raised issues, but weeding the central server's contents > in such a way seems to be impracticable.
Yay!
 /Stefan
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080627/a75236b3/attachment-0001.html>