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

[Argent Stonecutter]

On 06-Oct-2007, at 18:25, Andre Roche wrote:
>> I think the "instance" needs to be a long term object, as well. If
>> you edit a texture in your inventory, change its properties, its
>> identifier shouldn't change.

> So in a multisource system where I call for an asset by it's ID
> What permissions will it have when I recieve it?

Using Callum's terminology, you should get an instance of that asset,  
I think. That instance should be filled out by the source, using  
whatever policy it has... it may be a "master" instance that domain  
maintains, or it may be filled in with the local domain info. When  
you request that asset again, you should get the same instance (it's  
cached).

> Aside from that, do we even have a definition of what an asset is,  
> or can be?

I think we're trying to work that out now.

> Right now, we have a defined list of asset types.  Texture, Gesture,
> Clothing, etc.  For an extensible architecture, in a world where SL is
> a common thing, it needs to be versatile.

How about, at the highest level:

An asset is some kind of static data, with a MIME type indicating  
what the asset type is (image/jpeg2000, application/x-llNotecard),  
plus some instance properties that are inherited by copies. A copy of  
an asset contains a reference to and possibly a cached copy of the  
static data and a copy of the properties at the time. Compound  
assets, like gestures and clothes, have a set of properties including  
the static assets they're based on, along with references to any  
locally cached copies of those assets.

Raw static assets are transferred as the identifier, the mime type  
and an efficiently compressed blob. Instances are transferred as an  
encoded serialized form of the asset along with, if requested, copies  
of any required data. Conceptually like DNS, with back references and  
request types that can pull in more or less data. In practice,  
something like compressed XML followed by counted blocks containing  
blobs (since images and the like are generally already compressed).