[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