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

dirk husemann hud at zurich.ibm.com
Mon Oct 8 02:17:30 PDT 2007


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

-- 
dr dirk husemann, pervasive computing, ibm zurich research lab
--- hud at zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield



More information about the SLDev mailing list