I agree with removing the invtype, completly duplicate, I wanted to remove it for a long time. :)<br><br>but about asset's name and description, I have the same concern with your "1st disadvantage".<br>and also I do not think they are duplicate with inventoryitem's columns even they are not used currently.<br>
<span class="wordlink">To stretch a point</span><span class="wordlink"></span>, if you want only one name, the one should be deleted is the name of inventoryitem.<br>
<br>I would like to share my reasons:<br>1. Semantically,<br>Asset should keep its own information by itself but not refer to an external service.<br>* Asset name is just the name of itself, it is named by the creator, it is used to describe what the asset is.<br>
* Inventoryitem's name is a "nickname" named by inventory owner, its purpose is for quick understanding<br><span class="wordlink"></span><br>For example:<br>A picture's name could be "opensim_screen_shot_20020101", description: "screen shot of the<br>
1st release version of opensim, client: SLViewer, taken by test user", but in lulurun's inventory it could be called<br>"lulurun's favourite photo"<br><br>2. To think the way we are using assets,<br>
Asset service could become a large, indenpendent storage service, it contains objects in virtual worlds *but*<br>may not be *only* used by UGI R servers, it may have a different (web) interface to let users/grid_admins manage it.<br>
and in the future peple maybe trade/exchange/gift assets out of the world (by using other ways (website, mobilephone, email...) )<br>in that case asset name, description will be used directly(not from inventory).<br>//<br>
<br>As you mentioned in your major point of the advantages(the 1st one),<br>even with name, description, ... we can still put asset in a file like:<br>| body size | asset data | semantic information size | name, description, ... |<br>
this is just a example.<br><br>and, I am agree with developping a filesystem based asset server, it makes the program simple and easy to implement inside other httpserver.<br>most of all, the number of asset will become very large, and asset is not related to any other data, to use a RDB is a kind of waste and inefficient.<br>
but this is not going to replace current assetserver , for small grid or personal use, current assetserver can give a good enough solution.<br><br>So my personal opinion is remove invtype, retain name, description<br><br>
lulurun,<br>regards<br><br><br><br><div class="gmail_quote">2008/6/22 Justin Clark-Casey <<a href="mailto:jjustincc@googlemail.com">jjustincc@googlemail.com</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This is mainly a question for core developers, though other viewpoints<br>
are welcomed.<br>
<br>
In the OpenSim assets database table currently there are eight fields<br>
<br>
+-------------+-------------+------+-----+---------+-------+<br>
| Field | Type | Null | Key | Default | Extra |<br>
+-------------+-------------+------+-----+---------+-------+<br>
| name | varchar(64) | NO | | | |<br>
| description | varchar(64) | NO | | | |<br>
| assetType | tinyint(4) | NO | | | |<br>
| invType | tinyint(4) | NO | | | |<br>
| local | tinyint(1) | NO | | | |<br>
| temporary | tinyint(1) | NO | | | |<br>
| data | longblob | NO | | | |<br>
| id | varchar(36) | NO | PRI | | |<br>
+-------------+-------------+------+-----+---------+-------+<br>
<br>
Of these, name, description and invType are not really used by OpenSim<br>
(there are a couple of places in the code that use invType, but these<br>
could easily use other data sources). Name and description are a little<br>
pointless for assets - the real names and descriptions are actually<br>
always kept in the inventory items which reference these assets.<br>
InvType is also information which is always duplicated in items.<br>
<br>
Eliminating these fields would have the following advantages<br>
<br>
1. Make it easier to save and load and integrate assets with locations<br>
outside OpenSim. If you don't need to maintain name, description or<br>
invType, it should be possible to save assets with the uuid embedded in<br>
the filename and an extension which shows the asset type (e.g. .jp2 for<br>
JPEG2000 textures). The assets wouldn't require persistence of the<br>
local and temporary attributes.<br>
<br>
Two immediate use cases are that elimination of these asset fields would<br>
make the creation and manipulation of archives and inventory libraries<br>
much simpler. There may also be integration benefits. For instance,<br>
asset data files could be served directly by a stock webserver without<br>
having to wrap them in XML to provide the extra metadata). Moreover, if<br>
we adopt generation of UUIDs using a hashing algorithm (e.g. SHA1) at<br>
some stage, we wouldn't even need to embed the UUID in the name.<br>
<br>
2. Eliminate the code which maintains these fields, simplifying the<br>
codebase and making it easier to read. This is a minor point, since the<br>
amount of code isn't large.<br>
<br>
3. Reduce data storage requirements. This is also a minor point, since<br>
these fields will always be dwarfed by the blobs (although this might<br>
come into play much further down the line if blobs are moved out of the db).<br>
<br>
The one disadvantage I can think of is<br>
<br>
1. It becomes a little hard to get a sense of what's in your asset<br>
database by just browsing the assets table. For instance, you get a<br>
rough sense of how many objects are in prim or avatar inventories by<br>
counting the number of times that 'Primitive' appears as a name...<br>
However, statistical information could still be derived (if desired) by<br>
analysing the type field.<br>
<br>
In summary, I would like to see if the name, description and invType<br>
asset table fields can be removed at some point in the near future.<br>
Does anybody have a good or necessary reason to retain them?<br>
<font color="#888888"><br>
--<br>
justincc<br>
Justin Clark-Casey<br>
<a href="http://justincc.wordpress.com" target="_blank">http://justincc.wordpress.com</a><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Lulurun