[sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007
Argent Stonecutter
secret.argent at gmail.com
Thu Oct 11 12:06:28 PDT 2007
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.
More information about the SLDev
mailing list