<br><font size=2 face="sans-serif">A newly created region contains no assets
(except for terrain?). Objects get rezzed from OAR files and by avatars
moving things from their inventories, right? These objects reference other
objects and assets (textures et al) either directly or via object inventory.</font>
<br>
<br><font size=2 face="sans-serif">In principle, it is sufficient for the
asset database to reflect only those assets required to support the set
of objects considered to be part of the permanent region state at any given
point in time. Of course, I'm assuming here that the assets needed by an
objects that are subsequently rezzed can be resolved somehow. The approach
we have been experimenting with locally is to extend the "Not Found"
handling to search for an asset in a static/dynamic set of other known
asset repositories. This should make the process transparent to all.</font>
<br>
<br><font size=2 face="sans-serif">Weeding out abandoned assets can, as
everyone has said, by examining the point-in-time configuration of the
region's permanent state. This could be done by a separate process or low-priority
thread. As part of this approach it would seem logical to have a secondary
asset database. Moving the unreferenced assets to this "apparently
unused asset" database. If an asset is not resolved in the local asset
database then the first alternative location checked is the "apparently
unused asset" database. The search continues with other independent
asset servers according  to whatever search algorithm is in effect.</font>
<br><font size=2 face="sans-serif"><br>
Best regards<br>
Alan<br>
-------------------<br>
T.J. Watson Research Center, Hawthorne, NY<br>
1-914-784-7286<br>
alan_webb@us.ibm.com</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">Melanie <melanie@t-data.com></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">opensim-dev@lists.berlios.de</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">02/09/2009 10:33 AM</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: [Opensim-dev] AssetServer Observations
and Suggestions</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>In a normal grid use scenario (OSGRID) I believe that
most assets <br>
are _initially_ created by uploading them through the viewer. Even <br>
though they can be deleted, few people delete their textures, since <br>
they are always needed for further building. The savings would be <br>
minuscule, IMHO. Assets being implicitly shared, any textures passed <br>
to another user will link to the same inventory item, so that <br>
deleting something from one user's inventory doesn't mean that it is <br>
deleted from all users' inventories. There is no way to determine a <br>
reference but by scanning all inventories and all object assets.<br>
<br>
Melanie<br>
<br>
Justin Clark-Casey wrote:<br>
> Melanie wrote:<br>
>> All assets have, at some point, been on a user's inventory. There
is <br>
>> no way to upload anything without having it in inventory at some
point.<br>
>> The largest assets are textures, and they will always pass through
<br>
>> user inventories. Also, they will remain in user inventories despite
<br>
>> _also_ being on region objects. Making regions hold their own
assets <br>
>> authoritatively would cause massive data duplication, albeit <br>
>> distributed, and not really unclutter the central database.<br>
> <br>
> Assets can be loaded via OAR and other mechanisms that never flow
through inventory.  Also, I believe it's quite <br>
> possible to completely delete items from user inventory.<br>
> <br>
>> <br>
>> I believe a tag and reap mechanism that slow-scans all assets
for <br>
>> contained assets and all inventories for referencs and tags all
<br>
>> referenced assets, as well as regions transmitting "asset
lists" of <br>
>> assets currently referenced inworld, and the last use flag. Let
that <br>
>> run for 6 months, then reap all unflagged, reset all flags, and
<br>
>> start a new cycle.<br>
>> <br>
>> This doesn't have to be mutually exclusive, in fact it can be
<br>
>> combined with persistent local asset caching (e.g. local texture
<br>
>> storage for inworld objects) as well as a HG model.<br>
>> <br>
>> Melanie<br>
>> <br>
>> Diva Canto wrote:<br>
>>> Diva Canto wrote:<br>
>>>> Justin Clark-Casey wrote:<br>
>>>>   <br>
>>>>> An even more radical solution would be to switch osgrid
to a pure Hypergrid model.  The osgrid UAI services could still <br>
>>>>> act as the home services for many people who don't
want to run their own regions, but the responsibilty for maintaining <br>
>>>>> region-side assets would shift to other OpenSim instances
(and some people would also use them for their home services <br>
>>>>> instead of osgrid).<br>
>>>>><br>
>>>>>   <br>
>>>>>     <br>
>>>> I've been thinking about this too. I think it should be
possible, <br>
>>>> although we need to rethink a little bit the association
between users <br>
>>>> and UGAIM servers. Right now it's sort of bundled; we
need to unbundle. <br>
>>>> We could make an interface for the User server that would
allow users to <br>
>>>> set their servers.<br>
>>>>   <br>
>>> Actually, we don't even need to change the user base data.
The inventory <br>
>>> assets are only a [relatively small?] percentage of all the
assets in <br>
>>> the grid asset server. Most of the assets, I would say, are
inworld <br>
>>> things that aren't on any inventory. They are on the "region's
<br>
>>> inventory" so to speak. So we could move all regions
into HG mode, <br>
>>> setting the proper local servers in their OpenSim.ini's. The
users <br>
>>> inventory would still be OSGrid's Inventory server.<br>
>>><br>
>>> Even so, there are a few things that need changing/improving
for this to <br>
>>> happen. But it's not that far out.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> ------------------------------------------------------------------------<br>
>>><br>
>>> _______________________________________________<br>
>>> Opensim-dev mailing list<br>
>>> Opensim-dev@lists.berlios.de<br>
>>> </font></tt><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev"><tt><font size=2>https://lists.berlios.de/mailman/listinfo/opensim-dev</font></tt></a><tt><font size=2><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> Opensim-dev@lists.berlios.de<br>
>> </font></tt><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev"><tt><font size=2>https://lists.berlios.de/mailman/listinfo/opensim-dev</font></tt></a><tt><font size=2><br>
>> <br>
> <br>
> <br>
_______________________________________________<br>
Opensim-dev mailing list<br>
Opensim-dev@lists.berlios.de<br>
</font></tt><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev"><tt><font size=2>https://lists.berlios.de/mailman/listinfo/opensim-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br>