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

[John Hurliman]

dirk husemann wrote:
> John Hurliman wrote:
>   
>> Argent Stonecutter wrote:
>>     
>>> On 06-Oct-2007, at 15:42, Callum Lerwick wrote:
>>>       
>>>> "Almost all programming can be viewed as an exercise in caching"
>>>>         
>>> Yah. Caching was the thing that immediately sprang to mind as a
>>> problem with using a URL and making requests in real time. Resources
>>> need to live "close" to where they're used. Assets are going to get
>>> copied around. Assets referred to from in-world objects need to still
>>> work even if the asset server from Joe's Bar and Grid is offline, so
>>> they need to be cached.
>>>
>>>       
>>>> For this to happen, we need a way to unambiguously
>>>> identify an asset, completely independent of its location. A content
>>>> hash is probably the best way to do this. Duplicate copies of an asset
>>>> become obvious to identify, and likewise maliciously modified or
>>>> corrupted copies of the asset can be identified and culled.
>>>>         
>>> What about assets with editable properties, like clothing, gestures,
>>> notecards, and so on? 
>>>       
>> I don't know if this has already been answered in the thread, but
>> currently there is no such thing as an asset with editable properties.
>> If you change a word in a notecard and save it, you are uploading a
>> new asset to the grid. If you change the sleeve length of your shirt
>> and save it, you are uploading a new wearable asset (and new temporary
>> bakes for your final outfit).
>>
>>     
> which supports the change-an-asset-and-it-turns-into-a-new-asset faction
> --- which, i think, makes things much easier and reduces overhead and load.
>
> suggestion: asset: once created in-world is fixed. change permission,
> change description, change texture -> new asset. asset includes all
> properties. that way it can be cached without having to verify with the
> "originating" domain whether the creator has changed her mind...
>
> keep it simple.
>
>     cheers,
>     dirk
>
>   

In the current model, only changing the asset data itself causes a new 
asset to be created. An asset consists of the data + metadata which 
includes name, description, and permissions. This works out pretty well 
because a lot of people might be running the same script, or the same 
notecard might be handed out to 500 different people, or a popular 
clothing item might be owned by a large number of people. In those cases 
where nothing has changed in the asset data, they all link to the same 
uuid to download the actual data but the metadata is different for each 
one (at a minimum the OwnerID is changed).

That's just a description of the current model, but I think something 
similar might be a good approach for the future.

John Hurliman