[Opensim-dev] AssetServer Observations and Suggestions

[Teravus Ovares]

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 <melanie at t-data.com> 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
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>