Meeting notes from 15 Mar 2004 Users & Groups design meeting

Attending: AndiVajda, HeikkiToivonen, BrianDouglasSkinner, MitchKapor, KatieCappsParlante, ChaoLam, MimiYin, Scott, Lisa, TedLeung (by phone)

Previous meeting:

• 23 Feb 2004 -- see notes

Terminology Resolutions

Warning: Can't find topic Trash.SharingGlossary

Warning: Can't find topic Trash.TrueSharing

Resolutions

1. [Resolution]
   • Q: Does a Persona+ represent "another Chandler user who you share content with", or "a specific repository belonging to another Chandler user who you share content with"?
   • A: If a Contact has only one Persona+, then you can think of the Persona+ as representing "another Chandler user who you share content with".
   • A: A Contact can have two or more Personas+, where each Persona+ represents "a specific repository belonging to another Chandler user who you share content with". For example, my Contact item for Chris might have two Personas+, one for the "Chris at home" repository and one for the "Chris at work" repository.
   • A: If Mary has just one Repository, and Mary uses Replication to keep two copies of it in sync, at work and at home, then in my address book my Contact for Mary will have just one Persona+
2. [Resolution]
   • Q: If I want to share my calendar with Chris, and Chris has Chandler installed at home and at work, do I share my calendar with "Chris", or with "Chris at home"?
   • A: This will work just the same way that people use email today. If Chris has two repositories, Chris might give me just the address of one repository (in which case I share with that one), or Chris might give me the address of both repositories and then tell me what she uses each one for and explain when I should share things with one versus the other.
3. [Resolution]
   • Q: At which level do we associate the access permissions? Do we do automatic sync with one repository or with both (e.g. "home" and "work")? At which level do we keep track of what items need to be refreshed?
   • A: We associate access permissions with a Persona+, not with a Contact. We keep track of items that need to be refreshed on a per-Persona+ basis, not on a per-Contact basis. We do automatic sync just with the one repository associated with the Persona+ we shared with.
4. [Resolution]
   • Q: If a Principal item really represents "a specific repository belonging to another Chandler user who you share content with" rather than "another Chandler user who you share content with", then should we use some word other than "Principal"? Maybe something like "Foriegn Repository"?
   • A: Yes, we should use a different term. We couldn't think of a good term, so for now we're going to use the term Persona+.
5. [Resolution]
   • Q: In the user's mental model, we have Contacts and Groups. A group can have many contacts in it. A contact cannot have any other contacts in it. In the repository layer we just have Persona+, where any Persona+ can have sub-Persona+. How do we reconcile those two models?
   • A: In the repository-level data model, we may want to introduce the notion of a Repository-Group, which would be a type of Persona+. If so, then only Repository-Groups would have lists of sub-persona+, and Persona+ would not have sub-Persona+. But that's just one solution. We'll leave it to the repository group to decide how to do this. It may be that the repository ends up implementing some richer semantics which the Chandler app uses only some features of.
6. [Resolution]
   • Q: Should there be a kind called "Group"?
   • A: Yes. (And maybe a Repository-Group as well.)
7. [Resolution]
   • Q: Is there a 1-to-1 relationship between Group and Persona+ (each Group is a user-level representation of a repository-level Persona+)?
   • A: Yes. Or more specifically, there's a 1-to-1 relationship between a Group and a Repository-Group.
8. [Resolution]
   • Q: Can we say that Group will be defined in the same layer at Contact?
   • A: Yes.
9. [Resolution]
   • Q: Can we say that Group will be a sub-kind of Content Item?
   • A: Yes.
10. [Resolution]
    • Q: Should we have a kind that represents an "access permission"?
    • A: Maybe. Or maybe we want a lighter weight data structure. This is a technical design decision for the repository group.
11. [Resolution]
    • Q: Can an "access permission" be given just for Content Items, or to other types of items as well?
    • A: The design group only requires that users be able to share Content Items, Views, and Item Collections. The repository group might chose to implement a more general system in which any item can be shared.
12. [Resolution]
    • Q: Is there a notion of a "me" Contact? How is that modeled? Is there a notion of a "me" Persona+?
    • A: The end-user may have a notion of a "me" Contact, but that would be a feature of the UI and the application level code. At the repository level there are just Persona+, and the user "logs in" as one of these Persona+ (so that from the user's perspective, that Persona+ is "me" for the duration of the session).
13. [Resolution]
    • Q: Let's say I have a two computers, one at work and one at home, and each one has it's own copy of Chandler and it's own repository. I can share items between them using normal sharing. Is that sort of sharing just like sharing between any two repositories, or is it somehow different?
    • A: It's different. That's Replication, not True Sharing^?
    • Q: Do these two repositories "know" that they belong to the same "me" Contact, or the same Persona+?
    • A: Yes, they do.
    • Q: Do they automatically transfer Certificate info for the Persona+ of other people they share with?
    • A: Probably, yes.

Content Model Resolutions

• Chandler Level Data Structures
  • Contact
    • A Contact is a sub-kind of Content Item
    • Each Contact can have many Personas+ (e.g. "home" vs. "work")
    • Each Contact can be in many Groups
    • (See also the existing content model: Contact)
  • Group
    • A Group is a sub-kind of Content Item
    • Each Group can have many Contacts
    • Each Group can have one associated Repository-Group
    • (See also Remaining Open Issue #5 below)

• Repository Level Data Structures
  • Persona+
    • A Persona+ is a sub-kind of Item
    • Each Persona+ can appear in many different Contacts (e.g. just like two Contacts might have the same phone number)
    • Each Persona+ can be a member of many Repository-Groups
  • Repository-Group
    • A Repository-Group is a sub-kind of Persona+
    • Each Repository-Group can have one associated Group
    • Each Repository-Group can have many member Personas+
  • Access Permission
    • We don't yet know what data structures we want to use to associate access permissions with Personas+, Content Items, Views, and Item Collections.

Remaining Open Issues:

1. [Open question] Should we have a kind that represents an "X.509 Certificate"? Or maybe a Type instead of a Kind?
2. [Open question] Does each Persona+ have an X.509 Certificate? Or maybe more than one? Maybe one that represents the Persona-as-publisher and a different one that represents the Persona-as-subscriber?
3. [Open question] What are the attributes of a Persona+?
   • one or both of the following
     • a list of sub-Personas of this Persona+?
     • a super-Persona+ of this Persona+?
   • a list of access permissions granted to this Persona+?
   • one but not both of the following:
     • a list of Contacts that this Persona+ is associated with?
     • a single Group that this Persona+ is associated with?
   • a notification queue, which has a list of items (or a list of changes to items) that need to be transmitted to the foriegn repository whenever we can next connect to the foriegn repository
   • a connection address, so that we know how to find the foriegn repository and start a conversation with it (should this really be a list of addresses, some of which might use different routes or transports?)
   • an X.509 Certificate that we got from the Persona+, with
     • a "verfied" bit, which is true iff we have exchanged thumbprints to confirm the X.509 Certificate
     • a "trusted" bit, which is true iff the Certificate was created by a CA that we trust
     • a "revoked" bit, which is true iff this Certificate has been revoked or expired
   • a note about which X.509 Certificate we gave to the Persona+, with
     • a "verfied" bit, which is true iff we have exchanged thumbprints to confirm the X.509 Certificate
     • a "revoked" bit, which is true iff we have revoked this Certificate
   • a revokation queue, which might have a Certificate in it if we need to revoke our Certificate whenever we can next connect to the foriegn repository
4. [Open question] What are the attributes of a Contact?
   • can we agree that a contact will look like this?
5. [Open question] What are the attributes of a Group?
   • exactly one Persona+ associated with this Group
   • a list of the sub-Groups in this Group
   • a list of the Contacts in this Group
     • and, for each Contact in the list, we optionally keep track of
       • which phone number within the Contact is the chosen phone number
       • which email address within the Contact is the chosen email address
       • which Persona+ within the Contact is the chosen Persona+
       • which IM address within the Contact is the chosen IM address
       • which Contact Section within the Contact is the chosen Contact Section
6. [Open question] What does a "connection address" or "sharing address" look like? How do we find the foriegn repository and start a conversation with it?

Action Items

1. Replication
   • Mitch to own the problem of finding someone to take ownership of the replication project -- requirements, open issues, implementation options, etc.
   • Main.BrianDouglasSkinner to add this "Replication" project to the ProjectOverviewTable2005
2. Meeting notes
   • Main.BrianDouglasSkinner to write up notes from the meetings -- including resolutions, open issues, and who owns what follow-up items. (Done. You're reading it: Journal.UsersAndGroupsDesign20040315)
   • Main.BrianDouglasSkinner to create glossary terms for the different terms agreed on at the meeting. (Done, see #TerminologyResolutions above.)
3. Design doc updates
   • BrianDouglasSkinner to update the Users & Groups design doc to reflect the decisions made
   • Chao to update the Sharing design doc to reflect terminology changes and other decisions made
     • one detail that needs to change is the " What is shared?" bullet point in the Overview section. Needs to change to reflect the fact that we actually do share views, not just (an item collection with an associated recommended view type).
4. Heikki to make proposal regarding certificates
   • How many certificates are associated with each Persona+ (and each Repository)?
   • How are certificates modeled? Pros and cons of type vs. kind? How do we keep track of info like "revoked", "verified", etc.?
5. Installation Configurations
   • BrianDouglasSkinner to add this "Installation Configurations" project to the ProjectOverviewTable2005 -- (Met with Katie about this on 22 March 2004, and resolved not to create a separate project)
   • Katie to initially "own" the project, and work toward recommended resolutions of various questions, including:
     • How many copies of Chandler can one person install on one PC?
     • How many copies of Chandler can two people install on one PC?
     • Can two people who use one PC both use the same copy of Chandler?
     • When you launch Chandler, does it ask you to log in?
     • Can a single copy of Chandler be run against more than one Repository?
     • Can a single copy of Chandler be run against more than one set of UserRepositoryData?
     • In Canoga, can a single Repository have more than one set of UserRepositoryData?
6. Content Model
   • Main.BrianDouglasSkinner to write up high-level description. (Done, see #ContentModelResolutions above)
   • XXX to draft detailed content model design doc (or maybe parcel.xml)
   • Katie and/or Mitch to figure out if XXX is Katie or someone else
7. Access Control
   • Need to have some process for resolving all the things that fall in this bucket
   • Design group needs to drive design (user experience drives requirements)
   • Repository group needs to propose solution that fits with the design
   • Design group, apps group, and repository group all need to understand both the design requirements and the proposed solution.
8. Sharing
   • Need to resolve the remaining sharing issues, like the chain sharing issue. Owner? Chao?

• On Tuesday (16 Mar), after the meeting, we had a quick follow-up meeting with just Chao, Andi, Katie, and BrianDouglasSkinner. We have a few more action items that came out of that:
  • Chao to make one more revision of the access permission requirements. see CanogaAccessControlListDesign
  • Repository group to do some experimental coding work for a couple weeks, followed by some sort of informal proposal (or functional spec, or list of open issues) about the repository layer features and APIs related to personas+, access control lists, and new data model additions.
  • Content model group to make proposal offering first pass at a content model design for Groups, Contacts, etc. (Content model group is currently just Katie and BrianDouglasSkinner.)

---

Contributors

• BrianDouglasSkinner - 16 Mar 2004