hmm, well, I also note that terrainimages are used for the in-world map currently
Best Regards T On Sun, Feb 8, 2009 at 6:09 PM, Melanie <[email protected]> wrote: > Hi, > > Charles Krinke wrote: >> Each terrain edit appears to create a new "terrainImage" entry >> in the assets table and each time that happens, all previous terrain >> images become unlinked, unusable and unnecessary. > > As I mentioned in a separate post, I have a map that uses these > terrain images. Removing them would render the map unusable. I > believe thet region servers have better things to do than server > thousands of requests for their terrain image and that that sort of > HTTP traffic is not what a region server should have to endure, it > should serve a region, not be a webserver. > Therefore, a centralized store of terrain images is a good thing to > have. However, I do agree that the previous one can be deleted, if a > way can be found to do so safely. > Terrain images have the "Temporary" flag set, so should be safe to > delete when they are 1 day old and not referenced from the Regions > table. > >> A similar thing happens with scripts, notecards, and clothes. >> Prims themselves are stored in the regions datastore, so they >> dont apply to this discussion. > > These items are implicitly shared, therefore you can't just delete > the old version; someone may hold an inventory item with a link to it. > That is the inherent dilemma with the LL way of asset handling. > There are two basic approaches: A one to one asset<->inventory > mapping with mutable assets; this will create a new copy of each > asset for each time it is used of referenced in a user;s inventory, > or the current, read-only, implicitly shared asset architecture. The > current viewer doesn't support mutable assets, so that is not a real > option at the moment. > > Avoiding asset proliferation is not really possible at this time, so > I believe that pruning assets is the avanue that has more options > and that should be investigated. > > Melanie > > _______________________________________________ > 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
