[Opensim-dev] Please do not revert fixes without careful comtemplation

[Charles Krinke]

Dear Teravus:

No problem. The key point I was trying to make is that as time goes on we seem to be increasing exponentially the storage requirements in the UGAIM assets table. The terrainImage entry was an example of of an 'asset' that is a little different in perception then say, a texture covering a face of a prim.

This example was intended for us to think about those 'assets' which can be pruned on a regular basis so that our ability from the UGAIM viewpoint to find and retrieve an asset in a timely manner does not get so long as to make our sims performance degraded.

Charles




________________________________
From: Teravus Ovares <teravus at gmail.com>
To: opensim-dev at lists.berlios.de
Sent: Tuesday, February 17, 2009 6:39:52 AM
Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation

I thought it prudent to point out that the following statement is 100% fiction;

" 2. We have a significant number of assets of each and every edit of
terrain, where only the very last one is accessible"

What I think you meant to say was,

"2. Every two days each region generates a new map tile image and
names it terrainImage.  These do eventually add up"

Best Regards

Teravus

On Tue, Feb 17, 2009 at 9:31 AM, Stefan Andersson <stefan at tribalmedia.se> wrote:
>
>> > 1. We have a significant number of assets whose name is "blank" that are
>> > created with a default constructor. And I suspect are never accessible.
>>
>> In fact, this field has always seemed redundant to me since the user only
>> ever manipulates assets by their inventory
>> name, which is entirely separate from the asset name. The asset name is
>> never visible to the user (and afaik is not
>> used anywhere else in the code).
>>
>> At one point I thought about proposing to remove it. Possibly this issue
>> should be revisited.
>
> I believe it's kept there just as a convenience - to be able to get some
> kind of semantics, not necessarily exact, when browsing the table.
>
>> > 2. We have a significant number of assets of each and every edit of
>> > terrain, where only the very last one is accessible.
>>
>> Yes, this does seem wasteful to me since old terrain assets are not used
>> by anything, afaik.
>
> I have proposed a number of times that we could have a virtual asset_key as
> well as an asset_id - so that things that would rewrite assets could use the
> asset_key as an aux method to actually try to overwrite the asset. In the
> terrain case, the asset would be overwritten by key, not by id. This would
> allow us to implement a number of parallell schemas where some assets would
> be overwritten (asset_key = asset_id) and some where we would keep a history
> (only asset_key) and some where doing either or would be configurable.
>
>> > 3. We have a significant number of assets of each and every text edit
>> > for each and every textual assets. Where only the last one should be
>> > accessible.
>>
>> Unfortunately, this is not the case. For instance, imagine that you create
>> a script in your inventory. You drag this
>> script into a region object. At this point, both the entry in your
>> inventory and the entry in the region point to the
>> same textual asset.
>>
>> But then you edit the script in your inventory. After the edit it points
>> to a new asset containing the edited text.
>> However, the region object is still pointing to the old script asset. So
>> we need to keep both the old and new textual
>> assets.
>
> Not to mention the fact that the viewer caches stuff.
>
>> However, you're right in that textual assets which are never used
>> elsewhere (i.e. are intermediate edits that never get
>> dragged into an object, given to someone else, or otherwise transmitted)
>> might possibly be eliminated with some
>> sufficiently careful scheme.
>
> Binary de-duplication and added semantics in the form of 'key' or 'class'
> would probably go a long way.
>
>> > Its a bit like collecting every scrap of paper ever written with either
>> > text or binary glyphs and putting them in a big filing cabinet.
>> >
>> > After a while, finding the ones that are "interesting" in a "timely"
>> > manner starts to get a little "challenging".
>
> Let's keep the shining torch of this discussion burning.
>
> /Stefan
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090217/5734891a/attachment-0001.html>