<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:12pt"><div>Well, lets see if we can disect the problem a bit more and maybe take these issues one at a time.<br><br>I believe it may be a reasonable argument that the terrain of a region is a property of the region so that a regions terrain should be stored in the regions database and not on the assetServer database. In particular, I would argue that all the old terrain edits should be deleted from the assetServer database as they are not accessible or useful anymore.<br><br>Without even getting into any issues of inventory across regions, lets see if we can find a consensus on handling the current "terrainImage" that is stored on the assetServer and then go to another issue. I pick this one first as it seems more clearcut, but lets see how the discussion goes.<br><br>Charles<br></div><div style="font-family:
arial,helvetica,sans-serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Melanie <melanie@t-data.com><br><b><span style="font-weight: bold;">To:</span></b> opensim-dev@lists.berlios.de<br><b><span style="font-weight: bold;">Sent:</span></b> Sunday, February 8, 2009 12:37:52 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [Opensim-dev] AssetServer Observations and Suggestions<br></font><br>
Hi,<br><br>I think while some alternate scenarios are possible, the real <br>solution lies in pure "storage providers" that a user subscribes to, <br>and which are grid-independent, or in local storage on the user's <br>hard disk.<br><br>In the interim, we should maybe create a means to determine which <br>assets can be discarded. SPecifically, scan eacha nd every prim <br>asset to determine referenced textures and content items. Scan each <br>region to determine inworld item asset references. Tag all items not <br>found, wait a while, then judiciously delete.<br><br>Basically, the only resources that a script will reference by UUID <br>are textures and sounds. Animations cannot be referenced by UUID, <br>neither can other prim objects, unless god mode rez is used.<br>Wearables can't be referenced by asset ID either, so these will <br>always have an inventory item, be it in user inventory or inworld. I <br>believe that within about 6 months, equilibrium
will be reached, <br>e.g. a point where growth in the asset database is proportional to <br>the actual number of new items created, rather than just old copies <br>of edited items.<br><br>Assets on region is a bad idea, IMHO, because it means that region <br>operators are responsible for the inventories of users who have no <br>region at all, and user inventories would be available only if that <br>region happens to be up. in OSGrid, that can't be depended on.<br><br>Melanie<br><br><br>Frank Nichols wrote:<br>> I like the idea of shifting responsibility for user storage costs closer <br>> to the user. Region maybe a good place to do this.<br>> <br>> Frank<br>> <br>> Charles Krinke wrote:<br>>> We have been studying the assets table on OSGrid as it heads toward <br>>> the "disk full" stage and I have a couple of observations and am <br>>> heading towards a suggestion. Maybe this is already accounted for in <br>>>
the "Cable Beach" project, at which point, this will only indicate <br>>> that I did not read all the exchanges carefully enough.<br>>><br>>> It appears to me that we are storing on the MySQL data store at the <br>>> assetServer on a grid every edit of every script, terrainImage and <br>>> clothingItem amongst other things. So, my first observation is that we <br>>> appear to be storing all the older, obsolete items that can no longer <br>>> be accessed.<br>>><br>>> Additionally, it appears to me that we are also storing things that <br>>> could arguably be stored on the regions datastore, such as the <br>>> terrainImage.<br>>><br>>> Now, to the beginnings of a suggestion. It seems to me that each <br>>> avatar will have a "home" region. And that perhaps that is the place <br>>> to store the items in an avatars inventory. Things like scripts, <br>>>
notecards, textures and the like.<br>>><br>>> At that point, the assetServer on a grid could be used to store only <br>>> pointers (or URL's) to each avatars inventory on his or her home region.<br>>><br>>> So, by doing that, we start shifting the ever increasing disk storage <br>>> requirements of a grid back to the regions distributed around the <br>>> internet.<br>>><br>>> Again, perhaps Cable Beach is already doing this, and if so, this is <br>>> great. If not, I put out these ideas and duck as the tomatoes start <br>>> flying.<br>>><br>>> Charles<br>>> ------------------------------------------------------------------------<br>>><br>>> _______________________________________________<br>>> Opensim-dev mailing list<br>>> <a ymailto="mailto:Opensim-dev@lists.berlios.de"
href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>>> <br>> <br>> _______________________________________________<br>> Opensim-dev mailing list<br>> <a ymailto="mailto:Opensim-dev@lists.berlios.de" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>> <br>> <br>_______________________________________________<br>Opensim-dev mailing list<br><a ymailto="mailto:Opensim-dev@lists.berlios.de" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev"
target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br></div></div></div></body></html>