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

Justin Clark-Casey jjustincc at googlemail.com
Tue Feb 17 13:52:20 UTC 2009


Charles Krinke wrote:
> Well, it really doesnt matter what one calls them. Binary data, text, 
> whatever.
> 
> The point is that we have a number of issues with our assets table in 
> OpenSim that a bit of thought would help.
> 
> 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.

Unfortunately this is not true.  There are various mechanisms that create assets without giving them 'names'.

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.

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

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

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.

> 
> 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".
> 
> Charles
> 
> ------------------------------------------------------------------------
> *From:* Melanie <melanie at t-data.com>
> *To:* opensim-dev at lists.berlios.de
> *Sent:* Monday, February 16, 2009 4:43:53 PM
> *Subject:* Re: [Opensim-dev] Please do not revert fixes without careful 
> comtemplation
> 
> Yes, I did forget sounds. Probably because they never reached
> critical mass on any system I have anything to do with. Though, a
> lot seem to exist, judged by the number of gestures.
> As for images, I call them all "textures", because any image could
> be used as a texture. They are all jp2 steams, so even though they
> may have a different purpose from covering prims, they are
> technically identical in storage format and type of content, and
> would be handled the same.
> 
> Melanie
> 
> Justin Clark-Casey wrote:
>  > Melanie wrote:
>  >> No. Terrain images are textures. They are assets referring to jp2
>  >> streams. That makes them textures. And, AFAIK, all other assets are
>  >> text.
>  >
>  > Other non-text assets are images that aren't textures and sounds.
>  >
>  >>
>  >> Melanie
>  >>
>  >> Charles Krinke wrote:
>  >>> I am so sorry that we are having communications difficulties.
>  >>>
>  >>> Terrain Images, are, I believe, neither "textual" nor "text".
>  >>>
>  >>> That was just an example.
>  >>>
>  >>> The point is that we need to be careful and consider all the 
> various assets which include a lot more then textures and scripts.
>  >>>
>  >>> Charles
>  >>>
>  >>>
>  >>>
>  >>>
>  >>> ________________________________
>  >>> From: Melanie <melanie at t-data.com <mailto:melanie at t-data.com>>
>  >>> To: opensim-dev at lists.berlios.de <mailto:opensim-dev at lists.berlios.de>
>  >>> Sent: Monday, February 16, 2009 8:23:16 AM
>  >>> Subject: Re: [Opensim-dev] Please do not revert fixes without 
> careful comtemplation
>  >>>
>  >>> Hello,
>  >>>
>  >>> that was a typo. The correct word was "textual". All asset types
>  >>> besides textures are text.
>  >>>
>  >>> Melanie
>  >>>
>  >>> Charles Krinke wrote:
>  >>>> Sorry, the other assets are not just "small texture data". We have 
> terrainImages, amongst other things.
>  >>>>
>  >>>> Our assets table in OpenSim contains lots of things including the 
> infamouse "blank", so lets look at it in total and not just from the 
> script viewpoint.
>  >>>>
>  >>>> Course with scripts themselves, we have every edited version of 
> every edited script in addition to every change of every other asset 
> complicating the problem.
>  >>>>
>  >>>> Charles
>  >>>>
>  >>>>
>  >>>>
>  >>>>
>  >>>> ________________________________
>  >>>> From: Melanie <melanie at t-data.com <mailto:melanie at t-data.com>>
>  >>>> To: opensim-dev at lists.berlios.de <mailto:opensim-dev at lists.berlios.de>
>  >>>> Sent: Monday, February 16, 2009 4:44:56 AM
>  >>>> Subject: Re: [Opensim-dev] Please do not revert fixes without 
> careful comtemplation
>  >>>>
>  >>>> Again, I'd like to stress that I believe this is too dangerous to do
>  >>>> for anything other than textures.
>  >>>> It is also not really needed for things other than textures, since
>  >>>> the other assets are comparatively small, textural data.
>  >>>>
>  >>>> I would not want to risk even the smallest chance of a hash
>  >>>> collision on script source.
>  >>>>
>  >>>> Melanie
>  >>>>
>  >>>> Stefan Andersson wrote:
>  >>>>> Coming in a bit from the side here,
>  >>>>>
>  >>>>> 
>  >>>>>
>  >>>>> we have, for some time, discussed to separate out the binary blog 
> out of the metadata for an entirely different reason, namely to be able 
> to weed out binary duplicates.
>  >>>>>
>  >>>>>
>  >>>>> If there was a way for us to separate out the binary parts, into 
> something like 'binaryassetId, hashData[256], binarydata' and then just 
> have the asset table referencing that row, I think it would help a lot.
>  >>>>> 
>  >>>>>
>  >>>>> I realize it's a separate discussion, just chipping in my two cents.
>  >>>>>
>  >>>>>
>  >>>>> Best regards,
>  >>>>> Stefan Andersson
>  >>>>> Tribal Media AB
>  >>>>>
>  >>>>>
>  >>>>>
>  >>>>> 
>  >>>>>
>  >>>>>
>  >>>>> Date: Sat, 14 Feb 2009 17:49:22 +0200
>  >>>>> From: tommi.s.e.laukkanen at gmail.com 
> <mailto:tommi.s.e.laukkanen at gmail.com>
>  >>>>> To: mmazur at gmail.com <mailto:mmazur at gmail.com>
>  >>>>> CC: opensim-dev at lists.berlios.de 
> <mailto:opensim-dev at lists.berlios.de>
>  >>>>> Subject: Re: [Opensim-dev] Please do not revert fixes without 
> careful comtemplation
>  >>>>>
>  >>>>>
>  >>>>> Hello,
>  >>>>> 
>  >>>>> On second though we could keep the current structure and expose 
> all fields also through AssetBase properties. Then we could save / load 
> the AssetBase with nhibernate as a single object and leave out the 
> Metadata  property from NHibernate mapping. Does this sound good?
>  >>>>> 
>  >>>>> regards,
>  >>>>> Tommi
>  >>>>>
>  >>>>>
>  >>>>> On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur <mmazur at gmail.com 
> <mailto:mmazur at gmail.com>> wrote:
>  >>>>>
>  >>>>> Hi,
>  >>>>>
>  >>>>> On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen
>  >>>>>
>  >>>>> <tommi.s.e.laukkanen at gmail.com 
> <mailto:tommi.s.e.laukkanen at gmail.com>> wrote:
>  >>>>>
>  >>>>>> I was talking with mikkopa and he suggested we should create two 
> tables to
>  >>>>>> cover AssetBase to solve this issue properly. Namely 
> AssetMetadata for
>  >>>>>> metadata information and AssetData for blobs to avoid situation 
> where we end
>  >>>>>> up accessing also the blob data just to read metadata.
>  >>>>> I was hoping not to have to do that.
>  >>>>>
>  >>>>> It should be straightforward to support the current
>  >>>>> AssetBase/AssetMetadata composition in the existing OpenSim data
>  >>>>> layers, but as sdague warned me earlier, by mapping multiple classes
>  >>>>> to one table I was entering a world of pain. Seems that's exactly
>  >>>>> what's happening with NHibernate.
>  >>>>>
>  >>>>> The reason I introduced the AssetMetadata class is to supply metadata
>  >>>>> information only for some requests that Cable Beach, the new asset
>  >>>>> server, supports. Now I realize that this was probably a premature
>  >>>>> optimization.
>  >>>>>
>  >>>>> Instead of modifying the DB schema, we could have AssetBase inherit
>  >>>>> from AssetMetadata, as I outlined before[1]. Alternatively, we could
>  >>>>> get rid of AssetMetadata altogether and store everything in AssetBase
>  >>>>> as before, splitting out the metadata sometime in the future when a
>  >>>>> use case warrants it.
>  >>>>>
>  >>>>> What do you think?
>  >>>>>
>  >>>>> Thanks,
>  >>>>> Mike
>  >>>>>
>  >>>>>
>  >>>>> [1] 
> https://lists.berlios.de/pipermail/opensim-dev/2009-February/004918.html
>  >>>>>
>  >>>>>
>  >>>>>
>  >>>>>
>  >>>>> 
> ------------------------------------------------------------------------
>  >>>>>
>  >>>>> _______________________________________________
>  >>>>> Opensim-dev mailing list
>  >>>>> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>  >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>  >>>> _______________________________________________
>  >>>> Opensim-dev mailing list
>  >>>> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>  >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>  >>>>
>  >>>>
>  >>>>
>  >>>> 
> ------------------------------------------------------------------------
>  >>>>
>  >>>> _______________________________________________
>  >>>> Opensim-dev mailing list
>  >>>> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>  >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>  >>> _______________________________________________
>  >>> Opensim-dev mailing list
>  >>> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>  >>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>  >>>
>  >>>
>  >>>
>  >>> 
> ------------------------------------------------------------------------
>  >>>
>  >>> _______________________________________________
>  >>> Opensim-dev mailing list
>  >>> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>  >>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>  >> _______________________________________________
>  >> Opensim-dev mailing list
>  >> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>  >> https://lists.berlios.de/mailman/listinfo/opensim-dev
>  >>
>  >
>  >
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de <mailto: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


-- 
justincc
Justin Clark-Casey
http://justincc.wordpress.com



More information about the Opensim-dev mailing list