My goal in starting this whole discussion in the first place was two fold. Fold 1: Get us considering how to evolve OpenSim so that assets database currently containing 1.5million entries and consuming 50GBytes to support 10,000 users does not continue to grow without bound at the current 4GByte/week rate if possible. I see other grid deployments facing a similar issue in their future and some evolution at this point may help us all.
Fold 2: I believe there are a few changes such as the "last terrain image" store that we can change in the near term, and I am hoping we can define a 'reaping' strategy for grids that lets them tame the exponential growth of the 'assets' table in the MySQL database defined by OpenSim as 2009 continues. Charles ________________________________ From: Melanie <mela...@t-data.com> To: opensim-dev@lists.berlios.de Sent: Wednesday, February 18, 2009 12:20:42 PM Subject: Re: [Opensim-dev] oddities with asset storage There are several viewer being developed already and their authors are aware of requirements and responsive to different needs. Mainly, any new viewer will be able to accommodate changes quickly, unlike the LL viewer. So I see no need for a drawn out standardization discussion. This project is in too early a phase for this. Melanie Dirk Krause wrote: > Ok, granted. But isn't this a bit chicken/egg here? Possible solution > scenarios should define the requirements of the viewer, which probably won't > write itself. Esp. when new viewers will be based on openmv somebody should > tell John et al. :-). > > -----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 20:42 > An: opensim-dev@lists.berlios.de > Betreff: Re: [Opensim-dev] oddities with asset storage > > 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 > _______________________________________________ > 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