Melanie wrote: > This is something i have though about. However, it would not work in > OSGrid. Regions may go away, and they may go away permanently. > Anything in a prim inventory at that time is refcounted and would > not be released. Ever. > In what what in particular would this be worse than the current situation? Yes, some assets would end up staying around forever. However, unlike the current scheme, some... would not. > So, you'd need a ref list, to purge invalid refs. That is where the > inpracticability begins. A redf list for each and every asset, > listing either avatar UUID or region UUID? > > Eep, no - wasn't considering suggesting this. > If assets are 51 mio, how long will the reflist table be? > > Melanie > > Buckaroo Mu wrote: > >> Here's my L$0.02, for what it's worth - why not maintain a 'reference >> count' in the asset entry? >> >> Resident A creates a prim, takes it into inventory. Asset is created, >> inventory item pointing to asset is created, asset->useagecount++. User >> gives away 15 copies of item, asset->usagecount+=15. Resident A deletes >> original item, inventory item goes away, asset->usagecount--. >> >> Resident B rezzes item on sim. If item is no-copy, asset->usagecount--. >> If it's copy, and Resident B (or Resident C) takes it back into >> inventory, asset->usagecount++ (they would have two copies of it). >> Resident B deletes both copies from inventory, asset->usagecount -=2. >> >> If asset->usagecount == 0, asset gets deleted. >> >> Tell me why this wouldn't work. I'm sure there's a simple reason, but I >> can't think of it. All of this is assuming that the asset is no-mod - >> any change to the asset creates a new UUID, correct? But if the asset is >> rezzed, then taken back into inventory, it should have the same UUID, >> thus adding one to the usage count. >> >> -Buckaroo >> >> Melanie wrote: >> >>> All you described is design behavior. >>> >>> >>> Prim items in world are not assets. They are stored exclusively in >>> the prims tables of the region. >>> >>> Once taken, they become an asset. The name is totally meaningless, >>> it reflects whatever was the name at creation. Nothing else. It >>> never changes from there on. >>> >>> On deleting the inventory item, assets remain. There is no easy or >>> practicable way to conclusively say that an asset is trash, because >>> we don't know. >>> >>> In your test case, your (human) mind could know this for a fact, >>> however, the silicon mind of the asset server can't. >>> >>> This is because you may have given the object to another user, or >>> put a copy into a prim. >>> >>> These copies would refer to the same asset, that is what "implictily >>> shared" means. >>> >>> So, any asset may, at any time, have any number of links to it, even >>> zero. >>> >>> Like a website, you don't know who linked to it. If you remove it, >>> you leave dead links. Assets are the same. Except, you get "Asset >>> missing from database". >>> >>> So, assetas are NOT 1-to-1 with inventory items, and they _never_ >>> get deleted. >>> >>> They have to be reaped, and there is a big discussion over how to >>> best do that, running right now. >>> >>> Melanie >>> >>> >>> Dirk Krause wrote: >>> >>> >>>> Hi, >>>> >>>> I did a little test with a fresh OpenSim installation (yes, thanks for >>>> the installer!), >>>> to get a grip on what I learned from Melanie yesterday. >>>> >>>> I wrote a little python script to help me monitor these tables: >>>> inventoryStore/inventoryItems >>>> assetStorage/assets >>>> http://pastebin.com/mc9e6574 , be warned: ugly code. >>>> >>>> I started OpenSim and logged in a 'Test User' with the SL viewer. >>>> >>>> (Just to mention it - first time log in in as test users creates >>>> 4 'blank' entries in assets.) >>>> >>>> The inventoryItems table was initially empty. >>>> >>>> Now I rezzed a cube and renamed it to 'p1'. >>>> inventoryStore/inventoryItems was still empty. >>>> To my surprise no new entry shows up in assetStorage/assets. >>>> >>>> Picking up the cube ('take') created an entry named 'p1' in the >>>> inventory and in the asset table. >>>> >>>> Now I renamed the cube in Test Users inventory to 'p2'. >>>> The name in inventoryStore/inventoryItems changes to 'p2'. >>>> The entry in assetStorage/assets stays 'p1'. As mentioned on the list >>>> before, >>>> the asset name is useless, since the user only sees the name in the >>>> inventory. >>>> >>>> Now I deleted 'p2' in my inventory - 'p2's parentfolderID changes to >>>> 'Trash'. >>>> Now I emptied the trash - the inventory table is empty again, which is >>>> fine, >>>> but here's the big one: >>>> the assetStorage/assets still holds the reference to 'p1'. >>>> >>>> Just to make sure I shut down the simulator and opened it again, and it >>>> was still there. >>>> >>>> Now, doesn't that mean, that the database increases over time with no >>>> hope to find >>>> these assets that actually should be gone? or is there some magic >>>> purging that happens, >>>> and that I missed? >>>> >>>> This would mean that any grid runs into a severe problem over time. >>>> >>>> Best, >>>> Dirk/Bart >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> [email protected] >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected] >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >>> >>> >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > > >
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
