[Opensim-dev] Proposal to eliminate the name, description and invType fields from the assets db table

[liu xiaolu]

I agree with removing the invtype, completly duplicate, I wanted to remove
it for a long time. :)

but about asset's name and description, I have the same concern with your
"1st disadvantage".
and also I do not think they are duplicate with inventoryitem's columns even
they are not used currently.
To stretch a point, if you want only one name, the one should be deleted is
the name of inventoryitem.

I would like to share my reasons:
1. Semantically,
Asset should keep its own information by itself but not refer to an external
service.
* Asset name is just the name of itself, it is named by the creator, it is
used to describe what the asset is.
* Inventoryitem's name is a "nickname" named by inventory owner, its purpose
is for quick understanding

For example:
A picture's name could be "opensim_screen_shot_20020101", description:
"screen shot of the
1st release version of opensim, client: SLViewer, taken by test user", but
in lulurun's inventory it could be called
"lulurun's favourite photo"

2. To think the way we are using assets,
Asset service could become a large, indenpendent storage service, it
contains objects in virtual worlds *but*
may not be *only* used by UGI R servers, it may have a different (web)
interface to let users/grid_admins manage it.
and in the future peple maybe trade/exchange/gift assets out of the world
(by using other ways (website, mobilephone, email...) )
in that case asset name, description will be used directly(not from
inventory).
//

As you mentioned in your major point of the advantages(the 1st one),
even with name, description, ... we can still put asset in a file like:
| body size | asset data | semantic information size | name, description,
... |
this is just a example.

and, I am agree with developping a filesystem based asset server, it makes
the program simple and easy to implement inside other httpserver.
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.
but this is not going to replace current assetserver , for small grid or
personal use, current assetserver can give a good enough solution.

So my personal opinion is remove invtype, retain name, description

lulurun,
regards



2008/6/22 Justin Clark-Casey <jjustincc at googlemail.com>:

> This is mainly a question for core developers, though other viewpoints
> are welcomed.
>
> In the OpenSim assets database table currently there are eight fields
>
> +-------------+-------------+------+-----+---------+-------+
> | Field       | Type        | Null | Key | Default | Extra |
> +-------------+-------------+------+-----+---------+-------+
> | name        | varchar(64) | NO   |     |         |       |
> | description | varchar(64) | NO   |     |         |       |
> | assetType   | tinyint(4)  | NO   |     |         |       |
> | invType     | tinyint(4)  | NO   |     |         |       |
> | local       | tinyint(1)  | NO   |     |         |       |
> | temporary   | tinyint(1)  | NO   |     |         |       |
> | data        | longblob    | NO   |     |         |       |
> | id          | varchar(36) | NO   | PRI |         |       |
> +-------------+-------------+------+-----+---------+-------+
>
> Of these, name, description and invType are not really used by OpenSim
> (there are a couple of places in the code that use invType, but these
> could easily use other data sources).  Name and description are a little
> pointless for assets - the real names and descriptions are actually
> always kept in the inventory items which reference these assets.
> InvType is also information which is always duplicated in items.
>
> Eliminating these fields would have the following advantages
>
> 1.  Make it easier to save and load and integrate assets with locations
> outside OpenSim.  If you don't need to maintain name, description or
> invType, it should be possible to save assets with the uuid embedded in
> the filename and an extension which shows the asset type (e.g. .jp2 for
> JPEG2000 textures).  The assets wouldn't require persistence of the
> local and temporary attributes.
>
> Two immediate use cases are that elimination of these asset fields would
>  make the creation and manipulation of archives and inventory libraries
> much simpler.  There may also be integration benefits.  For instance,
> asset data files could be served directly by a stock webserver without
> having to wrap them in XML to provide the extra metadata).  Moreover, if
> we adopt generation of UUIDs using a hashing algorithm (e.g. SHA1) at
> some stage, we wouldn't even need to embed the UUID in the name.
>
> 2.  Eliminate the code which maintains these fields, simplifying the
> codebase and making it easier to read.  This is a minor point, since the
> amount of code isn't large.
>
> 3.  Reduce data storage requirements.  This is also a minor point, since
> these fields will always be dwarfed by the blobs (although this might
> come into play much further down the line if blobs are moved out of the
> db).
>
> The one disadvantage I can think of is
>
> 1.  It becomes a little hard to get a sense of what's in your asset
> database by just browsing the assets table.  For instance, you get a
> rough sense of how many objects are in prim or avatar inventories by
> counting the number of times that 'Primitive' appears as a name...
> However, statistical information could still be derived (if desired) by
> analysing the type field.
>
> In summary, I would like to see if the name, description and invType
> asset table fields can be removed at some point in the near future.
> Does anybody have a good or necessary reason to retain them?
>
> --
> justincc
> Justin Clark-Casey
> http://justincc.wordpress.com
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>



-- 
Lulurun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080622/146cba92/attachment-0001.html>