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

[Argent Stonecutter]

On 06-Oct-2007, at 16:53, Tao Takashi wrote:
> So why aren't they just copies? I think if you take caching too far it
> gets very complicated. E.g. you probably cannot make sure anyway  
> that every
> cached instance of a copy gets invalidated or changed once you  
> change the
> original object. I was thinking more about really copying the  
> object to the region
> domain once it gets rezzed. It might then have another URL on the  
> region domain
> (part of the URL might be some sort of UUID or internal ID).

Well, that's what I was thinking too. That's what confused me about  
Zha's comment, the implication that the asset and its properties  
would have a permanent home with a specific URL. It has to be copied  
around, but the properties don't necessarily make sense outside the  
the original domain, but they need to keep them so when you get back  
you haven't had them stripped out.

There's really two classes of assets:

1. Static content: textures, animations, and so on.
2. Dynamic content: gestures, notecards, and so on.

The static content could be cached, but the dynamic content needs to  
be copied when it's rezzed or edited.

Really, this would be simplified if logically every inventory item  
was treated as a compound object, with the texture inventory item  
containing the local editable properties and a reference to the  
global asset that is the actual texture. Within a single domain this  
wouldn't require any changes for native objects.

> What I thought was something like the scope a creator can define  
> once they give or
> rez the object. This might define in which circles it can be used.  
> Like scope can be
> "only that region", "all regions on this domain", "only trusted  
> domains of level X" etc.

That's what I was getting at a while back when I was talking about  
having as an attribute of an asset a list of certificates (or  
references to certificates in its domain, or similar asymmetric  
encryption keys). When a region requests an asset with a non-empty  
certificate list it would need to have a matching key to at least one  
of the certificates.

The creator wouldn't have to see the certificates, of course. They'd  
just have a list of names they could grant access to the asset.

So you could say your "Cool Prim Hair" could be exported to "SL Grid,  
Disney, AOL, and Offshore Casino Co-op".

A domain that didn't want to play the encryption game could just  
allow any asset in its domain to go to anyone. Or allow none.

I'm not sure that it would be meaningful to have restrictions tighter  
than a domain, particularly since you're maintaining local copies (in  
cache or in a local asset server) and transfers between regions in a  
domain wouldn't even be seen by the originating domain.