[Opensim-dev] Prim (Task) Inventory - initial thoughts for an implementation in OpenSim 0.6

Tue Dec 11 16:00:29 UTC 2007

On Tue, Dec 11, 2007 at 12:54:31AM +0000, Justin Clark-Casey wrote:
> Following some IRC conversations with MW, I've been thinking about how 
> we might implement persistent prim inventories (i.e. task inventories, 
> as the associated packets are called).  Here is my initial proposal on 
> the issue for OpenSim 0.6.  In the spirit of iterative, open source 
> development, this is probably not the most optimal design but rather an 
> attempt to identify a basic way of doing it now that won't cause time 
> consuming problems down the road.
> 
> As MW has outlined, there are two aspects involved in implementing 
> persistent prim inventories - persisting them in an avatar's inventory 
> and persisting them in a region.
> 
> I propose that in both of these cases we store the prim's inventory as 
> part of its XML serialization, which I believe is stored as an asset 
> when a prim (or prim group) is taken into an avatar's inventory.  
> Metadata about items in the prim's inventory (name, permissions, etc) 
> would be stored as part of the serialization.  

> However, all assets within that inventory (other prims as well as data
> such as scripts and textures) would be stored as separate assets and
> linked to the serialization by asset id.

If possible, I'd like to make this a bit more explicit.  It would be
nice to be able to queury across these inventory items without having to
do a deep parsing of data in the database.

It would be educational, at least for me, to see a "sample" of said
data.  My brain works better on examples than on descriptions.

> I believe this will work without too many changes for the avatar 
> inventory, since an asset server is already available in both standalone 
> and grid modes.  The same asset server is also available locally to a 
> region in standalone mode.  However, I expect it would be a bad idea to 
> fetch assets from the grid asset server every time a grid mode region 
> started up - both in terms of unscalable load and bandwidth costs.
> 
> So I would propose that as part of the implementation of persistent prim 
> inventories, we need a local asset server that acts largely as a cache 
> for the grid asset server.  When a prim is initially rezzed to a region, 
> the only additional data other than that which we should supply already 
> (name, description, etc), is the asset id representing the serialized 
> parts of the prim. (Actually, I suspect that we're serializing things 
> such as name and description which we arguably shouldn't be - as 
> evidenced by the fact that if I change the name of a prim in inventory 
> and rerez it, it comes back with the name it had when I originally took 
> it from the region).
> 
> On receiving the asset ID, the region immediately makes a request to its 
> local server asset cache for the serialized data in order to run any 
> scripts in the prim inventory.  If the asset is not found locally, then 
> the request goes out to the grid server.  Once the grid server supplies 
> the asset, it can be cached persistently locally (as assets never change).
>
> Once the asset is received by the original region calling code, it's 
> deserialized and loaded into memory.  The asset ids contained within the 
> prim inventory can be requested as required.
> 
> If any of the metadata for those contents changes, then a new serialized 
> asset is stored locally.  If any of the prim contents change (e.g. a 
> script is updated), then both the contents information (with the new 
> asset id) and the new script asset are stored locally.
> 
> If a user takes the prim into their inventory, we need to pass to the 
> grid the asset id holding the serialized aspects of the prim.  If this 
> doesn't exist on the grid asset server, the grid will need to make a 
> request for that asset to the local region asset server.  It will need 
> to deserialize this data and make requests in turn for any of the prim 
> inventory asset ids it's missing.
> 
> I believe the major cost of this scheme is that associated with the 
> [de]serialization of the prim.  I've thought through a few alternative 
> proposals which avoid this by establishing task inventory tables and the 
> like, but these all seem to become rapidly quite complicated as one 
> tries to account for things such as prims which exist inside themselves 
> and the reuse of item inventory entries (so that identical items don't 
> end up unnecessarily duplicating inventory structures).  The 
> serialization scheme has the wonderful virtue of simplicity (assuming it 
> works :-).

I think that if you specify a parent_id relationship, you can do this
pretty easily and recursively in tables in a reasonable way.  Having a
seperate parent_child inventory table will work reasonably well here as
well.  Perhaps if I have a few examples I can propose table models and
queries that will give you what you want here.

The inventory normalization (keeping a minimum number of inventory
items) needs to be thought of carefully, because unless they are
no-moddify, you will need to make copies at some point.  Delayed copy
might save some storage, but may make the code much more complicated.

> The local asset server scheme also potentially allows somebody running 
> many regions in one location to centralize their persistent region 
> storage into one database, which could aid administration, backup, 
> availability, etc.
> 
> Comments/suggestions/brickbats, please.

    -Sean

-- 
__________________________________________________________________

Sean Dague                                       Mid-Hudson Valley
sean at dague dot net                            Linux Users Group
http://dague.net                                 http://mhvlug.org

There is no silver bullet.  Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20071211/1981a871/attachment-0001.pgp>