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

Argent Stonecutter secret.argent at gmail.com
Sat Oct 6 11:21:56 PDT 2007


On 06-Oct-2007, at 11:15, Zha Ewry wrote:
> Unless I miss the mark badly, the intent is that any asset which  
> can be used by a service (ie has a public appearance) will have a  
> URL form.This should allow complete disambiguation as to which  
> asset server holds each asset.  With REST and the overall web  
> approach, when we want to know the extrinsic properties of an  
> asset, a properly formed query against the URL should/could result  
> in the properties being returned. In general, looking towards  
> existing REST style web resource patterns is the goal here.

I think you're talking about a different issue than I am. I'm talking  
about managing domain-specific properties associated with an asset,  
not the location of a specific copy of an asset on a particular asset  
server, nor the mechanism for accessing those properties.

First, whether you're accessing an asset from a remote server via a  
URL, or working with a local cached copy of the asset, or making a  
permanent copy of the asset in another region (for example, rezzing  
an object into the world), the properties need to be available.

Second, properties on an asset may originate in different domains...  
for example, a property that describes a characteristic of an asset  
that the original domain didn't support would be expected to be  
maintained, and it needs to avoid conflicting with any properties  
specific to the original domain.

Third, the domain a property is specific to is not necessarily  
defined by the location of the asset server. A property may be  
specific to a particular simulator software package, and so the  
domain of that property would be associated with that package, and  
any regions running that software would use the same domain  
identifier when setting that property. A property may even be  
specific to a viewer, set from the client, and treated as an opaque  
object by all regions.

So... it doesn't matter whether the identifier of a domain is a UUID  
or a URL. It doesn't matter whether it's fetched through multiple  
HTTP requests, or one HTTP request, or by any other mechanism.

There needs to be a mechanism to allow software to assign properties  
specific to a domain. These properties have to avoid conflicting with  
properties set by other domains, but they have to be enumerable and  
copyable so that they are maintained whether the asset is copied,  
cached, or always explicitly fetched.

The tuple { domain_id, creator_id, permissions, name, value } with  
{ domain_id, name } being a unique key. Creator ID and permissions  
are advisory, but useful to have there so that users won't be  
surprised when (for example) the changes they made to their jacket  
when they were in another grid get lost whenever they return home.  
Anyway, the tuple could be reduced to { domain_id, name, value }.

The key point is that the domain_id of the property should not be  
constrained to being the same as the domain of the asset server the  
asset is at that moment residing on.



More information about the SLDev mailing list