[Opensim-dev] AssetServer Observations and Suggestions

[Melanie]

Hi,

I have a map that uses the terrain image from the asset server. 
Removing it would break my map, since my map is designed not to 
contact any region server, since they have better things to do than 
serve images.

Melanie

Charles Krinke wrote:
> Well, lets see if we can disect the problem a bit more and maybe take these issues one at a time.
> 
> 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.
> 
> 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.
> 
> Charles
> 
> 
> 
> 
> ________________________________
> From: Melanie <melanie at t-data.com>
> To: opensim-dev at lists.berlios.de
> Sent: Sunday, February 8, 2009 12:37:52 PM
> Subject: Re: [Opensim-dev] AssetServer Observations and Suggestions
> 
> Hi,
> 
> I think while some alternate scenarios are possible, the real 
> solution lies in pure "storage providers" that a user subscribes to, 
> and which are grid-independent, or in local storage on the user's 
> hard disk.
> 
> In the interim, we should maybe create a means to determine which 
> assets can be discarded. SPecifically, scan eacha nd every prim 
> asset to determine referenced textures and content items. Scan each 
> region to determine inworld item asset references. Tag all items not 
> found, wait a while, then judiciously delete.
> 
> Basically, the only resources that a script will reference by UUID 
> are textures and sounds. Animations cannot be referenced by UUID, 
> neither can other prim objects, unless god mode rez is used.
> Wearables can't be referenced by asset ID either, so these will 
> always have an inventory item, be it in user inventory or inworld. I 
> believe that within about 6 months, equilibrium will be reached, 
> e.g. a point where growth in the asset database is proportional to 
> the actual number of new items created, rather than just old copies 
> of edited items.
> 
> Assets on region is a bad idea, IMHO, because it means that region 
> operators are responsible for the inventories of users who have no 
> region at all, and user inventories would be available only if that 
> region happens to be up. in OSGrid, that can't be depended on.
> 
> Melanie
> 
> 
> Frank Nichols wrote:
>> I like the idea of shifting responsibility for user storage costs closer 
>> to the user. Region maybe a good place to do this.
>> 
>> Frank
>> 
>> Charles Krinke wrote:
>>> We have been studying the assets table on OSGrid as it heads toward 
>>> the "disk full" stage and I have a couple of observations and am 
>>> heading towards a suggestion. Maybe this is already accounted for in 
>>> the "Cable Beach" project, at which point, this will only indicate 
>>> that I did not read all the exchanges carefully enough.
>>>
>>> It appears to me that we are storing on the MySQL data store at the 
>>> assetServer on a grid every edit of every script, terrainImage and 
>>> clothingItem amongst other things. So, my first observation is that we 
>>> appear to be storing all the older, obsolete items that can no longer 
>>> be accessed.
>>>
>>> Additionally, it appears to me that we are also storing things that 
>>> could arguably be stored on the regions datastore, such as the 
>>> terrainImage.
>>>
>>> Now, to the beginnings of a suggestion. It seems to me that each 
>>> avatar will have a "home" region. And that perhaps that is the place 
>>> to store the items in an avatars inventory. Things like scripts, 
>>> notecards, textures and the like.
>>>
>>> At that point, the assetServer on a grid could be used to store only 
>>> pointers (or URL's) to each avatars inventory on his or her home region.
>>>
>>> So, by doing that, we start shifting the ever increasing disk storage 
>>> requirements of a grid back to the regions distributed around the 
>>> internet.
>>>
>>> Again, perhaps Cable Beach is already doing this, and if so, this is 
>>> great. If not, I put out these ideas and duck as the tomatoes start 
>>> flying.
>>>
>>> Charles
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>  
>> 
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> 
>> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev