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

[dirk husemann]

Argent Stonecutter wrote:
> [...]
> The assets stored in it includes assets belonging to this domain, and
> copies of assets belonging to other domains. It may not be necessary
> to actually copy those assets from the other domain when only
> references to them are being transferred when (for example) an agent
> moves from one domain to another.
why do assets belong to domains? or, asked differently: what is "domain"
in this context? i might be thinking too simple (bear with me), but i'm
assuming assets belong to avatars/agents and are stored in asset servers.
>
> The agent server, or the asset server, contains copies of assets in
> user inventories. These copies may have different properties than the
> originals, these properties must be maintained, but there is no reason
> to retain a copy of the actual asset data in each copy.
i'm assuming the reverse: inventories contain references to asset servers.
>
> The region hosts, or the asset server, contain copies of assets that
> exist in regions. These copies may have different properties than the
> originals, these properties must be maintained, but there is no reason
> to retain a copy of the actual asset data in each copy.
there is: caching. and once i've rezz'ed an asset in-world in a region,
that asset should just stay as it is. if you want an object to track
changes made to a "master" object then that should be done via
scripting, not by having the region track the original. in the fast
majority of cases that would just be a waste or resources.
> [...]
> The architecture includes asset servers, region hosts, agent hosts or
> servers, and so on.
>
> However this is designed, all the states I listed must be able to be
> modeled in the design, efficiently. Transitions between these states
> must be possible. And that is where the architecture comes in... the
> architecture must be explicitly able to represent assets where the
> data is a reference to another asset, and to properties that are
> unknown to the asset server. The identifiers for properties must be
> unique, even for domain-specific properties.
why not keep it simple:

    * assets consist of meta data (properties) and asset data [i think
      we agree on that one]
    * assets belong to an avatar
    * assets are stored in asset servers
    * copying an asset creates a copy of the meta data/properties but
      retains a reference to the asset data
    * 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
    * inventories contain references to assets in asset servers
    * changing meta data/properties of assets in inventory goes back to
      the asset server that hosts that asset
    * 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
    * rezz'ing/copying/asset server copying are subject to the "usual"
      trust restrictions
    * modifying an asset has no effect on assets that have been rezz'ed
      previously
    * tracking changes to a "master asset" should be done via scripting

that way, rezz'ed objects are stable, the region domain doesn't have to
constantly check/track objects.

-- 
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/20071012/210e8f19/attachment-0001.htm