[Opensim-dev] oddities with asset storage

Wed Feb 18 21:03:09 UTC 2009

I hope I am not too notorious by stating:
- no 'big corp' IT manager will accept a solution with 'uncontrollable growth in asset storage' as Tommi correctly put it. Period.
- I learned through Melanie that these issue are well known and already addressed.
- I also learned that potential viewer developers are aware of these issues and have it on their list which is great.
- I also agree with Stefan that there should be alternative scenarios possible.

Von: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] Im Auftrag von Charles Krinke
Gesendet: Mittwoch, 18. Februar 2009 21:52
An: opensim-dev at lists.berlios.de
Betreff: Re: [Opensim-dev] oddities with asset storage

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 <melanie at t-data.com>
To: opensim-dev at 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-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] Im Auftrag von Melanie
> Gesendet: Mittwoch, 18. Februar 2009 20:42
> An: opensim-dev at 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-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] Im Auftrag von Melanie
>> Gesendet: Mittwoch, 18. Februar 2009 19:57
>> An: opensim-dev at 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 at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>> 
>>> 
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> 
>> 
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
> 

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev