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 <[email protected]> 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 > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
