[Opensim-dev] Inventory and assets

Tue Oct 9 09:51:46 UTC 2007

Well, Maybe I'm getting ahead of my self here. We could store the assets as binary blobs, just like we do today, but then we still have to face a number of issues:

1) Everytime any minor property in an asset changes, we have to store the complete set of aspects of the new asset, even aspects which hasn't changed, e.g. the name change of the texture in my sample below.
2)If my read of the code is correct, the sim is more or less ignorant of the various aspects of an asset, it simply shuttles the complete asset blob on to the viewer. In the long run this strategy cannot work, since the script engine needs the ability to modify aspects on an asset.

The above two changes will likely lead to scenario where storing an asset as a binary blob is no longer viable, leading to a change in the format of assets on the database backend, the question then arises, how to convert from the "old" blob format to the new one.

/Tleiades

> From: tleiades at hotmail.com
> To: opensim-dev at lists.berlios.de
> Date: Mon, 8 Oct 2007 23:16:04 +0200
> Subject: [Opensim-dev] Inventory and assets
> 
> Hi
> 
> As some of you might know, I have been working on a grid wide inventory 
> system. Actually I have a more or less complete implementation on my own 
> computers, but for various reasons, I have decided to release the code in 
> small incremental chunks.
> 
> Today I had a small setback. It turns out - or I had forgotten - that the 
> asset server isn't operational, all assets are stored locally on the running 
> sim. One way of thinking of the inventory, is to consider it a means for the 
> user to point to assets, i.e. an item in the inventory points to an asset in 
> the asset server. Consequently a grid wide inventory doesn't make much sense 
> until we have grid wide assets.
> 
> Consequently I am thinking about putting the inventory aside, and start 
> working on a grid wide asset server. Once we have that in place, I intend to 
> go back to the inventory.
> 
> I think that assets will be a big task, and quite complex, when considering 
> the ultimate goal for this project, so I aim for a first implementation, 
> wich will be functional, then we can pickup and refine that implementation 
> in a later iteration.
> 
> My thinking goes along the following lines:
> 
> 1) Create a functional asset server Using the REST methods sketched out in 
> the asset server code
> 2) Implement an asset cache on the sim, based on a reference counting 
> principle, the logic begin something like this:
>     On Rez
>         if(asset is in cache)
>             increment reference count
>         else
>             get asset from asset server
>             store asset in sim cache
>             set reference count to 1
>         end if
> 
>     On Derez
>         Decrement reference count
>         if(reference count=0)
>             remove asset from cache
> 
>     When avatar enters sim
>         Rez all attachments
> 
>     When avatar leaves sim
>         Derez all attachments
> 
> The only real big question now remains, what is an asset?
> From the outset, it can be seen as a file, containing either a binary stream 
> representing an image, sound bytes, scriptcode, prim shape definition. But 
> What happens when a scripted object is rez'ed, the code modifies the state 
> of the script or prim or the inventory of the object? If a script modifies 
> the link chain of a set of prims, changes the texture or any other mutable 
> property on a prim, do we have a new asset? if it is a new asset, do we copy 
> the textures into this new asset? Is the complete "file" changed, or only 
> parts of the file?
> 
> I know there is a huge debate on this going on on the sldev mailing list, 
> but I'd prefer to go for something resonably simple and practical, as a 
> first implementation.
> 
> My suggestion is based on the concept of triplets, much like the triplets in 
> RDF.
> 
> Basically an asset can be seen as a collection of values, each value 
> consists of three properties:
> 
> <assetid>, <type>, <value>
> 
> to give some examples
> 
> texture:
> 329AE20F-38C1-43fb-BDA0-6B13E569FCDF, Type, Texture
> 329AE20F-38C1-43fb-BDA0-6B13E569FCDF, Name, "Green grass"
> 329AE20F-38C1-43fb-BDA0-6B13E569FCDF, Width, 256
> 329AE20F-38C1-43fb-BDA0-6B13E569FCDF, Height, 256
> 329AE20F-38C1-43fb-BDA0-6B13E569FCDF, Image, 
> 44BD483173EC206D130B5F775B2B31D.........
> 329AE20F-38C1-43fb-BDA0-6B13E569FCDF, Owner, 
> 61AEA4D9-19CE-4fac-8E44-DFA24903BFB8
> 
> prim
> 61AEA4D9-19CE-4fac-8E44-DFA24903BFB8, Type, Primitive
> 61AEA4D9-19CE-4fac-8E44-DFA24903BFB8, Shape, Box
> 61AEA4D9-19CE-4fac-8E44-DFA24903BFB8, Position, 
> 8D45A164-52B1-4dab-A7BE-53A7078CA50B
> 8D45A164-52B1-4dab-A7BE-53A7078CA50B, X, 125.7
> 8D45A164-52B1-4dab-A7BE-53A7078CA50B, Y, 10
> 8D45A164-52B1-4dab-A7BE-53A7078CA50B, Z, 19
> 61AEA4D9-19CE-4fac-8E44-DFA24903BFB8, Size, 
> EA7254C0-D692-436a-949C-ADFE500E85EF
> EA7254C0-D692-436a-949C-ADFE500E85EF, Width, 10
> EA7254C0-D692-436a-949C-ADFE500E85EF, Height, 2
> EA7254C0-D692-436a-949C-ADFE500E85EF, Depth, 0.1
> 61AEA4D9-19CE-4fac-8E44-DFA24903BFB8, Name, "My plywood box"
> 
> On first inspection this seems to be too complex, but this scheme can easily 
> be extended to handle versioning, so in case somebody renames our texture in 
> the above example, this can be handled quite easily, by storing this 
> information:
> 
> texture
> 0CDE3656-D5A1-4ac2-819C-F8285680BC28, Parent, 
> 329AE20F-38C1-43fb-BDA0-6B13E569FCDF
> 0CDE3656-D5A1-4ac2-819C-F8285680BC28, Name, "Dark green grass"
> 
> in essence, this has created a new asset, called 
> "0CDE3656-D5A1-4ac2-819C-F8285680BC28", which inherits most of it's values 
> from "329AE20F-38C1-43fb-BDA0-6B13E569FCDF".
> 
> This is the strategy, which I'd suggest as a first go for assets, I would 
> welcome any and all comments
> 
> /Tleiades
> 
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev

_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20071009/2730ef27/attachment-0001.html>