- I also agree with you
Dirk Krause wrote:
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-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Charles Krinke
Gesendet: Mittwoch, 18. Februar 2009 21:52
An: opensim-dev@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 <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
begin:vcard
fn:Ideia Boa
n:Boa;Ideia
note;quoted-printable:Best regards,=0D=0A=
Ideia Boa=0D=0A=
WorldSimTerra=0D=0A=
=0D=0A=
Join the new 3D world revolution : http://www.worldsimterra.com/
x-mozilla-html:TRUE
url:http://www.worldsimterra.com
version:2.1
end:vcard
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
