In the viewer, the following are true: - The asset ID attached to an inventory item may not change - The item ID of an inventory item may not change - an asset's content may not change.
So, with this client, it's moot. We are exploring other concepts and will be implementing them as and when other clients become usable. Melanie Dirk Krause wrote: > There could be business modell attached to it. > Lets say you sell only the 'right to use it for a given time' to the user, > then you would have only one set of assets with multiple inventory pointers > from your 2000 customers. Once you delete/disable it, no one can use it > anymore. Once you update it, all 2000 have a newer version of it. The other > model would be the 'I buy it so I get a real copy of it'. The asset will be > copied (in my scenario to my local inventory domain, so I 'really' own it). > If you delete yours, mine is still there. If you update it, I need to obtain > a newer copy. There could even be a concept that something is there only once > (maybe art); you create it, give it a away (for a good price) and you don't > have it anymore. The asset vanishes from your inventory domain. > > Regarding the SL compatibility - maybe it doesn't need to be broken. IIRC > isn't there this CAPS mechanism that already proxies assets? Couldn't there > be some kind of intelligence behind it that collects and distributes assets > from the different domains? > > -----Ursprüngliche Nachricht----- > Von: opensim-dev-boun...@lists.berlios.de > [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie > Gesendet: Mittwoch, 18. Februar 2009 19:57 > An: opensim-dev@lists.berlios.de > Betreff: Re: [Opensim-dev] oddities with asset storage > > Making a copy is the greater evil. With implicitly shared assets, > only content creators create assets. With asset copying, each > sale/give creates assets. > Take SL: > > I make a clothing item. I have to make 18 uploads (creating 18 > assets) to finally use 2 of the uploaded textures. I have also > created 36 wearable assets through this. > > Then i put that item for sale. 2000 users buy it. > > With implicitly shared assets, assets consumed: 18 texture, 36 wearable. > > With asset copying, assets consumed: 4001 texture, 4003 wearable > > See, the point of diminishing returns for copying is very close. > > Melanie > > > John Ward wrote: >> Justin Clark-Casey wrote: >>> The problem is that you may have given that item to somebody else. >>> Giving an item does not make an asset copy, it just makes an >>> inventory item copy (both inventory items still point towards the >>> same asset). >>> >>> So you may delete your item, but we don't know if the asset >>> referenced by that item lives on in someone else's inventory (or in >>> an object inventory). So we can't delete the underlying asset. >> >> Why not make an asset copy when one makes an inventory copy? Then >> delete the asset when deleted from inventory. Is each user having their >> own copy of many things a bigger problem? I guess this doesn't address >> one having out of ban knowledge of an assets UUID and expecting it to be >> there. Also, I accept that I may be missing some fundamental knowledge >> of how things work. Please be gentle :-) >> >> John. >> _______________________________________________ >> 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 > > _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
