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

[Lawson English]

Argent Stonecutter wrote:
> 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).
>

Zha and I went around on this. From her high-level perspective, an asset 
is something that exists in a server outside the client, but that the 
client might get a reference of for some reason. A proto-asset would be 
some kind of information that no asset server knows about, that might 
someday, somehow be transformed/copied into an asset. There might be 
other kinds of data that exist client-side that wouldn't even be 
proto-asset in nature but you might still want to be displayed in the 
same list that an asset reference or proto-asset reference appears in (a 
proto-asset reference might be to a local texture file, or to a file 
accessable via ftp, etc).


L