it seems that the topic is changed to "UUID", I almost missed your reply,<br>thank you very much for your consideration,<br><br>lulurun,<br>regards<br><br>JustinCC<br><br><div class="gmail_quote">2008/6/24 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;"><div class="Ih2E3d">liu xiaolu wrote:<br>
> I agree with removing the invtype, completly duplicate, I wanted to<br>
> remove it for a long time. :)<br>
><br>
> but about asset's name and description, I have the same concern with<br>
> your "1st disadvantage".<br>
> and also I do not think they are duplicate with inventoryitem's columns<br>
> even they are not used currently.<br>
> To stretch a point, if you want only one name, the one should be deleted<br>
> 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<br>
> external service.<br>
> * Asset name is just the name of itself, it is named by the creator, it<br>
> is used to describe what the asset is.<br>
> * Inventoryitem's name is a "nickname" named by inventory owner, its<br>
> purpose is for quick understanding<br>
><br>
> For example:<br>
> A picture's name could be "opensim_screen_shot_20020101", description:<br>
> "screen shot of the<br>
> 1st release version of opensim, client: SLViewer, taken by test user",<br>
> but in lulurun's inventory it could be called<br>
> "lulurun's favourite photo"<br>
<br>
</div>I think that you make some valid points, Lulurun. Having thought about<br>
it a bit more, I agree that there is value in retaining the originally<br>
uploaded name for some assets, in particular those which always have<br>
meaningful original names on creation (such as textures). Although it<br>
doesn't make any difference from the client point of view, I can see<br>
uses on the server end (e.g. giving assets more meaningful names if they<br>
are exported).<br>
<br>
Description, I think, is more contentious. To my mind, this is<br>
information which should rest in the asset file itself (e.g. embedded<br>
within the jpeg2000 format of the texture itself. After all, this is<br>
the way it is handled within a common or garden filesystem).<br>
<br>
However, what I'm very probably going to do is simply look to remove<br>
InvType for now. I think that this is relatively uncontentious.<br>
<div><div></div><div class="Wj3C7c"><br>
><br>
> 2. To think the way we are using assets,<br>
> Asset service could become a large, indenpendent storage service, it<br>
> contains objects in virtual worlds *but*<br>
> may not be *only* used by UGI R servers, it may have a different (web)<br>
> interface to let users/grid_admins manage it.<br>
> and in the future peple maybe trade/exchange/gift assets out of the<br>
> world (by using other ways (website, mobilephone, email...) )<br>
> in that case asset name, description will be used directly(not from<br>
> 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,<br>
> description, ... |<br>
> this is just a example.<br>
><br>
> and, I am agree with developping a filesystem based asset server, it<br>
> 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<br>
> not related to any other data, to use a RDB is a kind of waste and<br>
> inefficient.<br>
> but this is not going to replace current assetserver , for small grid or<br>
> 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>
> 2008/6/22 Justin Clark-Casey <<a href="mailto:jjustincc@googlemail.com">jjustincc@googlemail.com</a><br>
</div></div>> <mailto:<a href="mailto:jjustincc@googlemail.com">jjustincc@googlemail.com</a>>>:<br>
<div><div></div><div class="Wj3C7c">><br>
> 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<br>
> 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>
><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>
</div></div>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a> <mailto:<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>><br>
<div class="Ih2E3d">> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Lulurun<br>
><br>
><br>
</div>> ------------------------------------------------------------------------<br>
<div><div></div><div class="Wj3C7c">><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>
<br>
<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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Lulurun