[Opensim-dev] AssetServer Observations and Suggestions

Sun Feb 8 21:25:19 UTC 2009

Hi,

i like charles idea and since i don´t have tomatoes shoot-ready give my view
as someone
who did large IT architectures for a while.

Pointers are perfect !

Pointer do not mean "point elsewhere" , so the very worthfull comment from
LC " opensim s*ks cause it lost all my asset..." maybe means for the short
term:  use pointer at the DB-level, but point to a local osgrid assetserver.

Pointer to a storageprovider will be the mid/long term view.  There will be
"full service grids" and open 3D web.
Most others will use a own database (public accessable) or provider. Just
how the world works today with e.g. blogs.

The idea of realxtend is a little bit that way, if you did ever play with
it.  

A little story from pointer in the Fileserver universe, just because they
are there quite long and the service is majure.   In former times, when a
fileserver was "full" , that was bad, because the name of the fileserver was
part of the share. So migration to new hardware was always complicated or
with pain for the user.  Thinking about merger and sales of company-disions,
same issue.  Years ago the company introduced points points (i.e. MS startet
with DFS ~NT4 Datacenter).  Now you access the pointers name and
splipt/migration scenarios are much painless. (if your architect did his
job)

So I would strictly vote for URI-style pointers.  All kind of scenarios
could use this.  And for the short term we could still stay to point to
local server , but even there a split on several machines or migration would
be easier.

Cheers,
Ralf
--
German opensim HowTo: http://www.ralf-haifisch.biz/Opensim%20HowTo.shtml 
Cybertechnews blog: http://opensim.cybertechnews.org/

------------------------------

Message: 4
Date: Sun, 08 Feb 2009 20:37:52 +0000
From: Melanie <melanie at t-data.com>
Subject: Re: [Opensim-dev] AssetServer Observations and Suggestions
To: opensim-dev at lists.berlios.de
Message-ID: <498F42A0.5000702 at t-data.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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
> 
> 