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

Argent Stonecutter secret.argent at gmail.com
Fri Oct 12 09:44:44 PDT 2007


On 12-Oct-2007, at 02:46, dirk husemann wrote:

> 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?

A domain could be any collection of resources that share some  
relationship that gives them the same trust model. A region domain,  
an asset domain, a trust domain.

> i might be thinking too simple (bear with me), but i'm assuming  
> assets belong to avatars/agents and are stored in asset servers.

Asset servers belong to domains.

>> 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.

So if you have assets belonging to 20 different private grids in your  
inventory you have to get data from all of them before you can see  
what you have?

>> 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.

If it's cached, it can expire from the cache if it's not referenced.  
That's how caching works... caching doesn't change the model of where  
things are, it just lets you avoid actually fetching the data from  
the official location every time... the real location remains the  
same, the cache is a copy invisible to the parent domain. The point  
is that there is no reason to retain a copy of the asset data (the  
actual texture) of every asset in every prim in the region other than  
performance.

In fact trust relationships between domains may not make it possible  
for a copy of the actual asset data to be made... ONLY the properties  
can be transferred.

> and once i've rezz'ed an asset in-world in a region, that asset  
> should just stay as it is.

Where in this paragraph do I say that it shouldn't? That's what  
"These copies may have different properties than the originals, these  
properties must be maintained" means. The properties of the asset in  
this domain, which may not be the same as the properties on the asset  
server in the original domain, must be maintained independently of  
the real location of the asset.

>  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.

I don't want an object to track changes made to a master object, I  
want a cached copy of an asset that is NOT intended to be turned into  
a logically separate copy to be able to copy back changes on the  
master, if the trust relationships between the domains allow it, when  
and only when the cached copy is transferred back to the  
responsibility of the original domain.

> 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 belong to an agent.

> assets are stored in asset servers

And regions, in the current model.

> copying an asset creates a copy of the meta data/properties but  
> retains a reference to the asset data

Plus, possibly, a cached copy of 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

The asset data shouldn't be copied unless it's actually needed.

UUIDs are internal identifiers, as I understand it, the global IDs  
are URLs.

> inventories contain references to assets in asset servers

The current model allows this. I don't think this will work with the  
distributed model, because asset servers are not going to be  
reliable. You have to have a local cache (either in the inventory or  
the asset server in the domain you're in) of the asset properties,  
but there's no reason to ALSO copy all the asset data into the domain  
(and in fact it may not be possible to, if you don't have the right  
trust relationship between the domain your inventory lives in and the  
domain the asset lives in).

> changing meta data/properties of assets in inventory goes back to  
> the asset server that hosts that asset

That can't always happen.

> 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 an asset causes an instance of the asset to be created. If  
it's a compound asset, then instances of the assets it uses may be  
created in the region. If the asset requires the data to be copied to  
the domain, then that's done. IT MAY NOT require copying the data,  
but the properties need to be available whether the data is copied or  
not (for example, to apply permissions).

> rezz'ing/copying/asset server copying are subject to the "usual"  
> trust restrictions

Yes.

> modifying an asset has no effect on assets that have been rezz'ed  
> previously

I don't think I've suggested it should.

> tracking changes to a "master asset" should be done via scripting

You don't track changes to a master asset, you apply changes from a  
master asset when it's "taken back into inventory" or otherwise  
transferred back to the domain the instance originated in.

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

Again, I don't think I said that the region domain needs to do any  
such thing.



More information about the SLDev mailing list