r2 - 12 Jul 2007 - 08:35:22 - MimiYinYou are here: OSAF >  Journal Web  >  MeetingNotes > SmallMeetingNotes > DesignIssuesMeeting20031124

Design Issues Meeting 24 November 2003

Attending: MitchKapor, BrianDouglasSkinner, MimiYin, ChaoLam, DuckySherwood

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

This meeting continued with the discussions of sharing started on 18 Nov and 20 Nov. We continued discussing the questions raised in SharingDesignIssues. (Some of these discussions will be reflected in SharingDesignIssues.)

Repositories

There was some discussion of relay servers -- a computer somewhere with lightweight administration that mirrors someone's primary repository for when they are off-line. Mitch wasn't sure if relay servering was a feature that we'd get in by Canoga. Brian suggested that if we had full replication and subscription-in-the-abstract, then we'd be able to get relay serving "for free". Mitch pointed out that there was a minor issue of what you saw when you sat down at the other machine. We have a model that there is one and only one instance of Chandler connected to one and only one repository. That would have to be expanded to support relay servers.

There was some discussion about how to log in to other people's repositories. Clearly, it would be nice if that were all transparent to the user. Mitch said that Andy Hertzfeld was planning on tackling Access Control Lists in the 0.4 release timeframe.

Push vs. Pull

We had a long discussion about push vs. pull. There is a tension between needing to support single-item sharing for Calendar Events (to support ITIP/IMIP calendaring specs) and Mitch's desire to stick to a model where items are only shared by ViewGroup. VCards came up as another case where you'd like to do single-item sharing. You'd like to be able to subscribe to all your friends' vCards, but you don't want to have 500 ViewGroups, each with one item.

Mimi noted that with IMIP, it isn't sharing in the Chandler Sharing sense of the word, but it feels like sharing because all the action is transparent to the user.

Perhaps the thing to do is to have a per-item sharing model for push and a per-ViewGroup model for pull. Brian asked what the difference between push and pull from a UI standpoint was. Mitch thinks that in pull-oriented transactions, notification is optional, while in push-centric transaction, notification is important.

There was some discussion of "share what you see". Mimi and Mitch had different interpretations of that phrase. Mitch had the impression that if at t=0, John shared what he saw (call it X), then at t=15 John moved to a different View, what John saw would be new (call it Y), so at t=15, John would be sharing Y instead of X. Mimi had been thinking that if at t=0, John shares X, John would continue to share X until John explicitly changed his sharing. At t=15 when John switches to seeing Y, John would still be sharing X. Mitch seemed to think that was okay, but pointed out that you'd need a way to easily see just exactly what you were sharing.

Summary

Consensus Items

  • It is highly desirable to have relay servers in Chandler by the Canoga release if it is not a lot of additional work.
  • Users can log into particular repositories on particular computers.
  • Users can run queries against someone else's repository.
  • While queries only run against one repository, multiple queries can be combined together in a View.
  • One of your Tasks can depend upon a Task in someone else's repository if you have subscribed to their Task.
  • One of your Tasks can not depend upon a Task in someone else's repository if you are only browsing that Task.
  • If Task A in one repository depends upon Task B in the same repository, where A is shared and B is private, users who browse or subscribe to A won't see that A depends upon B.
  • The Requestor field in a Task is user-defined. Some people will use it to mean the person who made the request; some people will use it to mean the person to whom the Task is owed. The burden will be on collaborative groups to negotiate a shared understanding.
  • Chandler must support sending meeting invitations by email.
  • It is highly desirable to be able to send and subscribe to vCards.
  • Should there be a checkbox in each of a user's Contact records for "notify this person when your contact information changes" to facilitate sharing (via push) the 'me' record?
  • Can a user have an Event in two different Calendars? If you subscribe to a set of Events, then want to pull an individual meeting to one of your own Calendars, can you do that while still getting updates about the meeting?

Open Issues

  • Are repositories always fully replicated, or can you replicate only part of a repository?
  • What do you see when you sit down at a relay server?
    • Is it running an instance of Chandler or different software?
    • Can one instance Chandler switch between different repositories?
    • Can multiple Chandlers run on one computer with different repositories for each?
    • How will users "log in" to a repository? What is the user interface and what is the authentication mechanism? Can the authentication be made transparent?
  • When will relay serving be released -- in Canoga? Later?
  • Can a Task depend on a Task in a different repository?
  • Is Requestor a multi-valued field or a single-valued field?
  • Will we support meeting invitations directly through Chandler Sharing, or only through email? Does having two separate ways to share items (email and Calendar Sharing) have implications/repercussions elsewhere?
  • Will we support handling Task delegation by email using the same mechanism as Calendar Event invitations?
  • How will we share free/busy information?
  • How will the user see what s/he has shared?

Factual Questions

  • If Joe invites Michelle to a meeting via IMIP, and Michelle accepts, which Calendar does the meeting go onto? Is there Calendar information embedded in the IMIP invitation?

Action Items

  • Ducky to write up meeting notes.
  • Unspecified somebody to rewrite issues documentation to take into account decisions that have been made.
  • Unspecified somebody to investigate what Calendar accepted invitations go onto in various commercial calendaring systems.

-- DuckySherwood - 25 Nov 2003

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r2 < r1 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.