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

Tue Jun 24 00:35:07 UTC 2008

it seems that the topic is changed to "UUID", I almost missed your reply,
thank you very much for your consideration,

lulurun,
regards

JustinCC

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

> liu xiaolu wrote:
> > 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"
>
> I think that you make some valid points, Lulurun.  Having thought about
> it a bit more, I agree that there is value in retaining the originally
> uploaded name for some assets, in particular those which always have
> meaningful original names on creation (such as textures).  Although it
> doesn't make any difference from the client point of view, I can see
> uses on the server end (e.g. giving assets more meaningful names if they
> are exported).
>
> Description, I think, is more contentious.  To my mind, this is
> information which should rest in the asset file itself (e.g. embedded
> within the jpeg2000 format of the texture itself.  After all, this is
> the way it is handled within a common or garden filesystem).
>
> However, what I'm very probably going to do is simply look to remove
> InvType for now.  I think that this is relatively uncontentious.
>
> >
> > 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
> > <mailto: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 <mailto:Opensim-dev at lists.berlios.de>
> >     https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> >
> >
> > --
> > Lulurun
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> --
> 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/20080624/b1f87be7/attachment-0001.html>