[Dev] Re: UUIDs of shared items (was Re: FYI: UUIDs of email messages)

[Morgen Sagen]

My expectation as a user is if we "stopped synchronizing" item 9876, 
that doesn't necessarily mean they're no longer the same item (your 
copy and my copy) -- it just means we're no longer sync'ing them up for 
the time being.  If we started synchronizing them again, I would assume 
any changes made to this item on either side would get merged.  In 
other words, they continue to be the "same" item even if we sever the 
sharing relationship.  If I decided that I wanted my item to be 
distinct from yours, I would make a copy of it in my repo.  Seems like 
more of a hassle if shared items don't have the same UUID, since you 
have to keep track of "equivalency" in some other way (like you said, a 
"shared item ID").

On the other hand, if you ever wanted to have both your copy and my 
copy of the shared item in the same repo (in order to facilitate 
conflict resolution perhaps), they would need separate UUIDs I think.  
Another case would be if you want to keep multiple versions of an item 
over time -- do we implement that in the repository layer as a single 
item with history info or as multiple items with separate UUIDs?  At 
what level of the strata does versioning take place?  Data model or 
Content model?  Darn, I hate raising more questions than answers.  :-)

~morgen


On Aug 11, 2004, at 2:59 PM, Lisa Dusseault wrote:

> There's a really tricky case if you try to make them the same.
>
> I share an event with GUID 9876.  You synchronize to it, and now you 
> have 9876 as well.
> You link 9876 into some of your own calendars.
> I stop sharing event 9876 (or you stop synchronizing to my share).
> You make changes to 9876 that are not reflected in my repository since 
> we've stopped sharing.
> Now, what happens if you share your calendar back to me?  You're 
> sharing event 9876 which is one I already have, but they're not 
> intended to be the same any more.
>
> One possible approach to this is to use the same GUID, but when the 
> sharing relationship is cut off, change all the GUIDs for things that 
> you're keeping.
>
> Another possible approach to this is to use different GUIDs from the 
> start.  Instead of using GUID equivalency to see if something is the 
> same, we'd publish some stable ID for a shared resource (possibly, in 
> fact, the GUID) and when that's downloaded remember that as the 
> "shared item ID", different from the locally-meaningful GUID.
>
> Lisa
>
> On Aug 11, 2004, at 2:44 PM, Morgen Sagen wrote:
>
>> Actually, the issue I'm wrestling with is not so much the identity of 
>> an email message item itself, but rather the UUID of a content item 
>> being shipped as payload.  Say I have a calendar event item that I 
>> want to share with you.  I get it to you either via email or webdav 
>> or carrier pigeon; you now have a copy of my calendar event item.  
>> Does your item have the same UUID as my original item?  Stuart 
>> explained that in his implementation the two copies of the item would 
>> have different UUIDs (whereas my assumption has always been they 
>> would have the same UUID).  There are benefits to each approach I 
>> think.
>>
>> I'm cc'ing Lisa in case she has any guidance.
>>
>> ~morgen
>>
>> On Aug 11, 2004, at 2:37 PM, Ducky Sherwood wrote:
>>
>>> Morgen Sagen wrote:
>>>
>>>> Hi Ducky,
>>>>
>>>> When I say UUID I'm referring to the chandler repository UUIDs, as  
>>>> opposed to an email's Message-Id, but thanks for the input.
>>>
>>>
>>> Yes, I understand -- my point was that you might not *need* UUIDs to 
>>> be the same in Jane's and Bob's repository because the message-ID 
>>> would be the same.  If you need to do a search, you can search on 
>>> message-ID instead of UUID.
>>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2377 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/dev/attachments/20040813/b638120a/smime.bin