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

[Teravus Ovares]

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
>
>