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

Wed Feb 18 07:04:49 UTC 2009

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090218/d3e1f860/attachment-0001.html>