Design Issues Meeting 5 Jan 2004

Attending: MitchKapor, ChaoLam, BrianDouglasSkinner, DuckySherwood

(Editor's note: these notes are my best understanding of what we believed on 5 January 2004. There are few guarantees that this will be an accurate depiction of reality in the future.)

(This was a short meeting due to a scheduling conflict.)

Today we went through CanogaSecurityDesign and CanogaSharingDesign20040419. Chao had circulated it already to JurgenBotz, KatieCappsParlante, and HeikkiToivonen, and the dev mailing list. He had incorporated a number of comments by the time of this meeting.

Security

Brian raised the issue that these were just two examples of what he sensed would be ever more common -- documents that are co-owened by the Design group and developers. It wasn't clear to him who owned these documents -- Chao or Heikki. Mitch said that Product Management owns the spec, but that nothing is a "go" until it gets Engineering buy-in. Chao noted that the share of responsibilities would be different for different projects. For example, he thought that in the Security project, Development would have a larger role than in most others. Chao voiced the opinion that as long as there was overall progress, an exact, formal apportionment of responsibility was less important.

(Something that was mentioned several times over the course of the meeting was the importance of specific use cases and storyboarding. Mitch felt that specific cases would either make the answer blindingly obvious or reveal a fundamental flaw in our design.)

The biggest issue was one of scalability -- a username/password would be required for every user for every repository. Mitch said that he felt that if we let users assign their own password, we are no worse off than the abundance of Web sites that all have username/password pairs.

Someone mentioned that they have one password that they use for all of their "low security" Web sites and a different strategy for "high security" sites. This clearly means that passwords can't be stored in the clear (since we don't want the repository owner to be able to guess at passwords the user might use elsewhere), but we didn't want to store in the clear anyway.

Sharing

We talked about an issue of user IDs, users, Contacts, Jabber IDs, and how they should all relate. Mitch opined that as an admin, he should be able to set up an account for someone, and if some new random person showed up and used that username/password, it should be fine. Brian pointed out that we don't have a 1:1 mapping between Contact and Jabber ID (or whichever ID we end up using), and that it would be convenient to have the UI present sharing at a Contact level, not at a Jabber ID level. In particular, it's common to have home and work settings; it would be nice if one didn't have to explicitly share with spouse-at-home-Jabber-ID and spouse-at-work-Jabber-ID.

There was then some discussion about feature prioritization. In the sharing document, Brian was surprised to see that "schedule a group meeting" was listed under "Canoga waitlist use cases". There was some discussion breaking down the different features associated with invitations:

1. sender sends an event as an attachment, recipient can drag that event onto their calendar
2. workflow: user accepts or counterpropose, that information is transmitted back to the original sender.
3. meeting organizer can see free/busy of the invitees
4. meeting organizer can create a shared event (where changes to the event are propagated around)

Mitch feels that #1 is clearly in Canoga, #2 is waitlisted, and #3 is "double waitlisted". #2 and #3 are orthogonal, but #4 is not.

There was some discussion of what happens if a View is destroyed -- is the ItemCollection no longer shared? Mitch felt that this should work like the Web: if a page is deleted on the server, then you don't get to see it in your browser any more.

There was some head-scratching about whether a URL should refer to an ItemCollection (since that is in fact what is shared) or on a View (since that's the primary affordance and since Views can have multiple ItemCollections). We deferred that decision.

Brian wondered how "annotating" Items -- modifying Items that were in a remote repository -- would work. A user might want to subscribe to an Item, edit it with the changes propagating back to the original, and/or edit it with changes remaining private. How will we keep track of which is which? In the Remote Browsing case, there are no edits made (or allowed), so that one's easy. In the replication case, it gets trickier. Mitch will think about that case.

Brian posed this question: can the situation arise where Brian creates an Item in Chao's repository, but doesn't have permission to grant access to others to see it? Mitch said yes, that while all editors have equal read/write access rights, the administrative privileges went with the repository and not the item.

Chao asked if "replication" was the right terminology. He had previously used "subscription" or "synchronization", but those don't adequately capture the sense of being able to write as well as read.

We had a brief discussion of caching. Chao felt that caching was an implementation detail germane only to the current session. (We realized that we'd someday need to define what "a session" was.) Mitch felt that long-lived caching was potentially more confusing than valuable. Chao pointed out that we can be smarter than most caches, but Mitch pointed out "smarter caching" looked like "replication". Mitch said that "caching" comes out of the client/server world, the client version is inherently "inferior" to the server version. The more dynamic the data is, the worse caching works. He thinks that in our network of peers, we should steer people into making replicas instead of cached copies.

Summary

Consensus Items

• Product Management owns the specs for design features, but Development needs to buy into them.
• Using username/password for each user for each repository is acceptable.
• An agent which would alert you if all the people you wanted to meet with were on IM is probably in Canoga.
• Everyone who has permission to edit an Item has equal access rights as all the other editors.
• Administrative privileges are tied to the repository, not to the Item.

Open Issues

• What is "a session" in the Chandler world?
• How will Item annotation work?
• What's the right way to share with someone who has multiple IDs?
• Should URLs refer to ItemCollection or to Views?
• What meeting invitation functions will be in Canoga?

Action Items

• Somebody to develop specific use cases and storyboards to illustrate requirements, including:
  • Setting up sharing with someone who has multiple Jabber IDs.
  • More fine-grained use cases for meeting invitations, including event scheduling combined with event sharing.
  • Should URLs refer to ItemCollection or to Views? (Brian)
• Somebody, presumably Chao, to clean up the language in the documents slightly:
  • CanogaSecurityDesign informally talks about sharing views, while CanogaSharingDesign20040419 explicitly says that Views won't be shared.
  • The security doc mentions "users" when it probably means "unique ID" (e.g. Jabber ID or email address).
  • More precisely define "schedule a group meeting" under "Canoga waitlist use cases" in the sharing doc.
  • Change "ItemCollection" to "ItemCollections" in the first bullet point under "Anatomy of a view" in the sharing doc.
• Mitch to think about annotating (modifying) items which are shared and come up with a solution.

-- DuckySherwood - 05 Jan 2004