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

[Melanie]

NHibernate has, in tests, been significantly slower than native
implementations.

Melanie

Antti Kokko wrote:
> Trying to catch up but anyway what I think in general is that the whole
> database schema is not the best in terms of coherence, associations etc. For
> me it seems that at first came all functionality and them came the database
> solutions. The structure feels is "broken" but I understand it because of
> grid mode etc.
> 
> What I`d like to see is simply one db solution which covers mysql, mssql and
> sqlite and that is most propably NHibernate. Why do all the updates to all
> interface implementing classes instead of doing it only in one place. I
> think this could save some serious time.
> 
> However I try to get to the asset discussion:
> 
> First of all I really like the way of Cable Beach and truly hope this all is
> going to distributed asset system. One of the biggest issues is cache,
> external cache etc. If we have e.q. publisher who wants to update an object
> in Cable Beach which is already used in sim1 and sim2, how we send the
> update to all caches? How I have understood it the current system is a kind
> of trade-off and actually new object is created instead of updating the
> existing one. On the database side I`d definitely like to see not a new
> object but an update. What I`ve heard the cache issues are long discussed
> and not easy to resolve and we definitely need a further discussion about
> along with Cable Beach or any distributed asset system. After all why I
> couldn`t have an apache web server somewhere where my asset, avatar, avatar
> appearance are.
> 
> Having several asset storages distributed all over the web we need an UUID
> for the asset but we are going to need of course an URL as key too. That is
> definitely one issue.
> 
> Best,
> 
>   - Antti
> 
> 2009/2/17 Charles Krinke <cfk at pacbell.net>
> 
>> 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
>>
>> _______________________________________________
>> 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