[Opensim-dev] Inventory and assets

Wed Oct 24 07:04:25 UTC 2007

As of my understanding, most assets are re-created; ie, a script gets a new guid on re-compilation, textures get new ids on upload, objects get new id's on duplication et.c - this is a good thing, since it allows for 'older versions' of assets not to be disturbed by updating.

Then of course, there is stuff like notecards, which I'm a bit unsure of how they actually work in SL.

Funny that you should mention RDF since I was once involved in building an open source RDF-based application framework, which ultimately proved to be totally useless due to the use of triplets for everything.

I would strongly advise against 'tall and thin' asset tables, as that approach, however convenient at first glance, always leads to grief in the end.

Also, don't forget that for some assets it actually makes a lot of sense having them served by the region; rezzed prim inventory is never acessed outside of the region, and textures are dynamically streamed to the client (not just straight streaming, but parts here and parts there and a couple of different sizes to mix) presumably depending on camera, avatar and regional context.

/Stefan

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20071024/97253960/attachment-0001.html>