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 >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev