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