No. Terrain images are textures. They are assets referring to jp2 streams. That makes them textures. And, AFAIK, all other assets are text.
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
