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. 2. We have a significant number of assets of each and every edit of terrain, where only the very last one is accessible. 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. 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 <mela...@t-data.com> To: opensim-dev@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 <mela...@t-data.com> >>> To: opensim-dev@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 <mela...@t-data.com> >>>> To: opensim-dev@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.laukka...@gmail.com >>>>> To: mma...@gmail.com >>>>> CC: opensim-dev@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 <mma...@gmail.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen >>>>> >>>>> <tommi.s.e.laukka...@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@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
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev