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

dirk husemann hud at zurich.ibm.com
Tue Oct 9 23:07:06 PDT 2007


Argent Stonecutter wrote:
> On 09-Oct-2007, at 07:42, dirk husemann wrote:
>> even if it's no-transfer?
>
> Sure, what does that have to do with it?
you wrote:
> * Permissions are inherently advisory between domains.
> * Some metadata, like owner and group, can always be modified even if
> the object is no-mod.
>   
if yo change owner & group, doesn't that constitute a transfer? with a
no-transfer asset you'd go against the wishes of the creator then.
>> i'm still struggling with the master copy concept: is the scenario that
>> you take some object with you to a "foreign" domain (i.e., you copy it
>> to the foreign domain), you modify the metadata of that object in that
>> foreign domain and then want to have those changes reflected back to
>> your native domain?
>
> Sure.
OK.
>
>> i can see where i'd want this for stuff i wear. what about stuff i leave
>> behind? or is this only applicable to worn objects?
>
> It can apply to stuff you never even rez in that domain. You might
> make a change to something in your inventory in a domain that has the
> same trust level as the original domain, you don't want those changes
> lost when you return.
stuff i leave behind: that is in my view like dropping a snap-shot. it's
not coming back with me. i would not expect changes that i inflict on it
in the other domain to have repercussions on the original asset.

inventory changes: that raises the interesting question of whether my
inventory is modulated by the domain i'm in? in other words, will my
inventory change depending on where i am or will i always see my full
inventory, i just won't be able to rez some items in certain domains?
again, i'd expect to always see the full inventory in my client, any
changes that i make are relayed back to the asset server of the item.


-- 
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