Sharing/repository meeting April 19

These journal notes are a reconstruction of some of the important scenarios and thoughts, more than a set of notes of who said what. I tried to strike a balance between representing what the meeting covered and in explaining scenarios and concepts in a more organized fashion than happened in the meeting. Thus, stuff is completely out of order and some images were replaced by new text details. --Lisa

Item UUID conflict sharing example

This example was constructed to see if there were problems using the same UUID in two different user repositories to represent a shared event. Let's say the same UUID is used.

1. Lisa shares Lisa's calendar containing an event "Henry Rollins concert" with a UUID '1234'.
2. When Andi looks at Lisa's calendar he decides to drag this concert to his own calendar because he also wants to attend it. Now he's got the event with UUID '1234' appearing both in Lisa's calendar and in his own calendar. An assumption here is that the same event is linked into both calendars. (The counter-assumption would be that the event would be copied when it's dragged - but in that alternative, changes Lisa made wouldn't show up in the event on Andi's calendar) See InteractionDesignSpec for more thoughts on what happens when you "drag" something.
3. Lisa stops sharing Lisa's calendar. Let's make another assumption -- that when Andi's repository figures out that this calendar is no longer shared, it retains the concert on Andi's calendar with the same UUID.
4. Andi may make changes to the event, even changing the meaning of the event altogether. Sometimes users do this -- they replace an existing event with a new event by editing the subject, place, etc -- so in this case, replacing "Henry Rollins concert" with "Piano student recital".
5. If Andi now shares his calendar to users including Lisa, Lisa would now see a "conflict" between "Piano student recital" and "Henry Rollins concert" -- two events with the same UUID. That would be bad because at some point Andi intended to make a whole new event. Instead, the desired behavior at this point is for Lisa to see that Andi is now attending a Piano student recital without seeing any relationship between that and the original concert.

Ideally, the UUID would change at some point in this process (or the event would need re-creation, either way would solve the problem). There are several points where this could happen.

• When Andi first synchronizes Lisa's calendar his repository engine generates a new UUID. This is the "no repeated UUIDs" model. It's possible that Lisa's repository's UUID never gets communicated, or that it's only used as a resource ID to make replication more robust.
• When Andi drags the event onto his own calendar he makes a copy -- a new item with its own UUID.
• When Lisa stops sharing the calendar, Andi's repository engine removes the item from all calendars, including Andi's own.
• When Lisa stops sharing her calendar but Andi's repository engine decides to keep the event it generates a new item with a new UUID.
• When Andi shares the item, we know he can't "reshare" it, so it's copied with a new UUID.

Variations, issues

There are a number of interesting variations, depending on when the UUID is changed, and how well things work.

• If the UUID is changed only sharing is terminated, can we tell when that event occurs with good reliability?
• If the UUID is changed only when Andi shares the event in a separate "share", at that point do changes to the original stop getting reflected in changes to the item he shared?
• What if Andi shares the concert event with Stuart, after step 3 above, and then Stuart tries to view Lisa's calendar?

Resharing

Steps 1 & 2 as above, then Andi's calendar is shared to Stuart (and note that Lisa's calendar is not shared to Stuart, and Andi can't add Stuart as a member to Lisa's share). The polite thing to do is for Stuart to see that Andi plans to attend "Henry Rollins concert", but to see no information about whether I intend to also see the concert. It would be rude (and probably accidental) for Andi to share with Stuart the fact that Lisa had this item on her calendar.

To solve this case as well as the conflicting UUID case, we might choose the point when Andi drags the concert to his own calendar OR reshares the item to make an item copy rather than an item ref.

Derived Values

When an event is shared, what information should be conveyed regarding each attendee? We want events to have attendees linked to rich contact information, but we don't want to necessarily share all that rich contact information. Let's assume the following item cloud stored inside the origin repository:

• EVENT
  • Item ref to Attendee item 1
  • Item ref to Attendee item 2

• ATTENDEE item 1
  • Item ref to Contact A
  • "hidden" flag true

• ATTENDEE item 2
  • Item ref to Contact B
  • "hidden" flag false

When EVENT is shared to somebody with "read" privileges on the event but who doesn't have "read" privileges to either contact A or B, what is shared is: attendee 2's full name, attendee 2's principal ID, as derived from the contact.

When EVENT is shared to somebody with "admin" privileges on the event, but without "read" privileges on A or B, what is shared is: both attendees' full names and principal IDs.

When EVENT is shared to somebody with "read" privileges on the event , who also has "read" privileges to contact B, what is shared: attendee 2's full name, attendee 2's principal ID, plus some information (a URL? a UUID) to allow the reader to follow the link to the contact and see more about Contact B.

When EVENT is shared to somebody with "admin" privileges on the event, who also has "read" privileges to both contacts, what is shared: both full names, both principal IDs, plus two URLs/UUIDs to allow the reader to follow the links to the contacts.

Principal IDs

We agreed that principals have unique IDs which are used on many repositories to refer to the same individual. This might be how that happens.

• Andi installs Chandler and Chandler generates a UUID to refer to "Andi the principal". This is his Principal ID.
• Chandler engine gets a public/private key pair.
• When Andi uses Chandler to communicate with other Chandler users, the communication includes his principal ID, signed by his private key. It also includes his public key.
• Other users save Andi's principal ID and his public key for future reference.
• When other users share items including Andi in the ACLs, they use Andi's Principal ID as well as the name "Andi Vajda". This dual information ensures that other users synchronizing those ACLs can see who the item is shared to even if they haven't seen his principal ID before -- they can still just display the name. OTOH, for repositories that have cached Andi's Principal ID previously, they probably have access to more information (the public key, possibly more information in the contact, such as email addres and phone #).
• Event attendee lists, when shared, should include full names, principal IDs and possibly email addresses (if an invitation was sent by email, in particular, it's good to know if it was sent to "andi@work.com" or "andi@home.com". )
• Email to/from lists, when shared, should include full names, principal IDs and definitely email addresses.

Note that when I say that this information should be "shared" I don't necessarily mean it shouled be "stored" in the item. So an ACL might be stored internally with only the principal ID -- but when the ACL is synchronized by some other chandler they may need to receive more than just the principal ID to make it work. It's easy enough for the repository to generate that information on the fly because it would link ACLs, attendee lists and to/from lists to more information including the full name.

Searching derived values

In the meeting we discussed whether derived values were compatible with searches -- if an attendee's full name is a value that is only derived from the contact that the attendee links to, then will the event turn up in searches?

(After the meeting, I thought some more and figured out that searches had better be smart enough that if a user name is searched for, and that name maps to a Contact, then the search ought to return every item cloud that the Contact has a bidirectional link to. Since in our Event content model assumed above, the Event has a bidrectional link to an attendee item and the attendee item has a bidirectional link to the contact, the search engine should be capable of following the links back to the Event and listing the Event as a match for that user. This is an interesting use case for searching in general. --Lisa )

Issues to discuss more

• Do item clouds overlap?
• What is the relationship between item clouds and permission inheritance?
• Does every item have an ACL or a specific place to inherit permissions from?

-- LisaDusseault - 20 Apr 2004