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

[Argent Stonecutter]

Here's part of a message that I was going to forward to the list, and  
I was waiting on an OK from the recipient before forwarding the whole  
thing. They haven't responded, so I've stripped out the first part  
because i think this might explain where I'm coming from a bit better...

Talking about the inventory...

[...]

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.

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.

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.

The region hosts in this domain may have cached instances of assets  
stored in this domain's asset server, and assets stored in other  
domains asset servers. These do not have distinct properties, but it  
is useful to treat them the same way as copies.

Different domains may have different properties that they need to  
track on an asset. These properties need to be maintained by whatever  
asset server the asset is maintained on. These properties need to be  
copied in copies of the asset. These properties are subject to  
different policies in different domains... a domain may not allow  
certain properties to be changed except from certain domains.

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.

For example, a texture may look like this (using a pseudo-RFC822  
style for compactness only, this isn't HTTP headers):

   Owner: http://example.com/agents/uuid
   Creator: http://example.com/agents/uuid
   Name: Snapshot_001
   Date:...
   ...
   Body-length: 102567

   jpeg-2000 image file

Or it may look like this:

   Owner: http://example.com/agents/uuid
   Creator: http://example.com/agents/uuid
   Name: Snapshot_001
   Date:...
   ...
   Location: http://example.com/something/filename.j2c
   Body-length: 0

That's a reference. It may be a cached instance that hasn't been  
fetched yet, it may be a copy. Or it may look like this:

   Owner: http://example.com/agents/uuid
   Creator: http://example.com/agents/uuid
   Name: Snapshot_001
   Date:...
   ...
   Location: http://example.com/something/filename.j2c
   Unknown-001: domain=http://raytrace-vr.example.com render-priority=26
   Unknown-002: domain=http://ferengi.example.com resale-royalty='35 %'
   Body-length: 102567

   jpeg-2000 image file

That's a reference with domain-specific properties and a local copy  
of the data.

The *architecture* has to explicitly ensure that (a) assets can refer  
to other assets, and (b) properties that the asset server doesn't  
know about are handled.