[sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007

dirk husemann hud at zurich.ibm.com
Thu Oct 18 00:29:56 PDT 2007


Callum Lerwick wrote:
> On Fri, 2007-10-12 at 09:46 +0200, dirk husemann wrote:
>
> Huzzah, someone else seems to be agreeing with my view. :)
>
>   
>> why not keep it simple: 
>>       * assets consist of meta data (properties) and asset data [i
>>         think we agree on that one]
>>     
>
> Meta data = "Asset instance", Asset data = "Static asset data"
>   
[plus later]

> An asset instance is metadata and a reference to static
> asset data stored in asset servers.


i might be nit picking on words here, but i think finding good terms is
as essential as the stuf being described: could we use "asset reference"
instead of "asset instance"? instance for me has the connotation of the
*whole asset* instantiated somewhere.

...on the other hand i can see where asset reference can confuse the
reader. ok, let's stick with asset instance. :-)
> We need to be clear on which we're talking about. 
>   
exactly :-)
>   
>>       * assets belong to an avatar
>>     
>
> Asset instances belong to avatars. Static asset data is a blob of bits
> with no intrinsic location or ownership.
>   
well...someone must have uploaded the asset data at some time, following
current SL practice, i'd call that the creator. thus, my assumption that
we'd always have asset data + meta data.

thus the following definitions:

asset: consists of asset properties (meta data) and actual asset data
(e.g., image, sound file, etc). it belongs to the creator.
asset instance: consists of asset properties (meta data) and a reference
to an asset --- i'd like to keep a link to the whole asset including the
original asset properties, hence the reference to the whole of the asset
and not just the asset data.

>>       * assets are stored in asset servers
>>     
>
> Static asset data is stored in asset servers. Asset instances are stored
> in the "Agent domain".
>   
[later:]
>>       * rezz'ing an asset causes a copy of the asset to be created;
>>         the region domain can decide to use the reference to the asset
>>         data or it can decide to do an asset server copy
>>     
>
> Rezzing copies an asset instance from the agent domain to the region
> domain. An asset instance is defined to be a reference to static asset
> data. If the region server needs the static asset data for something,
> such as collisions and physics on prims, it can retrieve it. But that's
> a region implementation detail.
>   
so, we probably agree that asset references/asset instances are stored
in agent domains (as part of inventories) and on region domains (as the
result of rezzing).

>>       * copying an asset creates a copy of the meta data/properties
>>         but retains a reference to the asset data
>>     
>
> Copying an asset instance [...]
>   
so, that now would be:

    * copying an asset creates an asset instance consisting of a copy of
      the asset properties and a reference to the original asset.
    * copying an asset instance creates a copy of the asset properties
      and a copy of the reference to the original asset

>   
>>       * assets can be copied to another asset server in which case the
>>         asset data is copied as well and a new UUID created for it
>>     
>
> See, here's where things get confused. Static asset data can be copied
> and cached freely as needed. As its "UUID" is a content hash, a copy can
> NOT have a different UUID.
>   
ok.
> Copying an asset instance, yes. But asset instances aren't handled by
> "asset servers", but by "agent servers".
>
>   
>>       * inventories contain references to assets in asset servers
>>     
>
> Inventories are a collection of asset instances, stored in an agent's
> agent server. An asset instance is metadata and a reference to static
> asset data stored in asset servers.
>   
ok.


>   
>>       * changing meta data/properties of assets in inventory goes back
>>         to the asset server that hosts that asset
>>     
>
> Editable properties are part of the asset instance. So changes go to
> your agent's _agent server_ not an asset server.
>   
ok

>   
>
> Note that I really want SL to move to more of a "There" like inventory
> system. Which means there needs to be a way for Agent servers to keep
> track of where your inventory is rezzed. We also need inventory
> thumbnails of some sort. :)
>   
thumbnails would/could be part of the asset properties (meta data).
keeping track of rezzed assets is another discussion point. let's first
settle how we define asset :-)

    cheers,
    dirk

-- 
dr dirk husemann, pervasive computing, ibm zurich research lab
--- hud at zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071018/9a6c5376/attachment-0001.htm


More information about the SLDev mailing list