r78 - 12 Jul 2007 - 08:34:54 - MimiYinYou are here: OSAF >  Journal Web  >  ProductManagement > CanogaSharingDesign20040419

Sharing Design

I moved this page to Journal because a lot of the stuff (including the Canoga target) is out-of-date. However there's still a lot of useful stuff that hasn't been reproduced in the main Projects wiki so at some point we should cherry-pick from this. --Lisa



Chandler will offer a variety of features to make it easy for users to share content with each other.


Warning: Can't find topic Trash.SharingGlossary

  • List of People You Share With-- - A list of people or Groups that the repository owner (sharer) can potentially share with. (Or, strictly speaking, not people, but Contacts -- or more strictly still, Persona+.) For a sharee to be included in someone else's List of People You Share With, they must be a Chandler user. The sharer first extends an invitation to the sharee. If the sharee accepts, an automated response is returned back to the sharer, including the sharee's X.509 certificate which is now stored as part of the user's Contact info. Once the sharee is on the sharer's SharingGlossary? Circle, the sharer can then add the sharee to AccessControlList(s) of the sharer's collections and ContentItem(s).

Warning: Can't find topic Trash.TrueSharing

  • Remote Browsing - Remote Browsing is a type of Trash.SharingGlossary?. In remote browsing, a user receives a URL of a remote item or item collection (or set of item collections in a view). On navigating to this URL and with the appropriate permissions and correct authentication (see Chandler.CanogaSecurityDesign?), the user can browse the remote item or item collection specified by the URL, just as you would browse a remote web site. Remote browsing (as opposed to True Trash.SharingGlossary?) is a transient or short-lived sharing mechanism. Use cases include browsing a public event calendar or a vendor phone directory (you only view such items once or non periodically). Remote browsing can be read-only browsing or read-write "browsing".
    • See Glossary: Trash.SharingGlossary?
    • See Glossary: True Trash.SharingGlossary?
    • See CanogaSharingDesign?

  • Dumb Copy - People can always select an item in a view and then copy the item and paste it somewhere else. The original item might be one that the user saw while doing Remote Browsing or while doing True Trash.SharingGlossary. But in either case, the new copy is a completely independent item that knows nothing about the original. The new copy belongs to the user who made the copy. The new copy is a Dumb Copy, not something that is Shared?.
    • See Trash.SharingGlossary?

  • Synchronization - We're using the word Synchronization to talk about keeping a non-Chandler data store in sync with a Chandler User Repository, or to talk about keeping items in sync between two User Repositories, if those items have been shared using True Trash.SharingGlossary?. Synchronization is different from Replication, which is what a person uses to automatically sync two or more User Repository Replicas in a Replica Set.
    • See Chandler.PDAandSyncAnalysis?

  • Publish - In the context of True Trash.SharingGlossary?, one user Publishes an item so that another user can Subscribe.

  • Subscribe - In the context of True Trash.SharingGlossary?, one user Publishes an item so that another user can Subscribe.

  • Unresolved sharing terminology [OI?]
    • "Roster" vs. "Sharing Circle" vs. "Sharing Network" vs. "Buddies List" [need a better name]
    • "local proxy"
    • "Notify" with a capital "N"
    • "notification" with a lower-case "n"
    • "1-time send" (identical to "Dumb copy"?)
    • "resend"
    • "True sharing" [need a better name]
    • "Dump copy" (identical to 1-time send?) [need a better name]

  • Other terminology, used just within this document
    • Sharer = a person who creates an item in their own repository and then makes it available to a sharee
    • Sharee = a person who views or edits an item that was created and shared by another user, the sharer

  • Repository terminology [OI?]
    • server repository -- all the items being served up by a single Chandler server. A server repository can include many user repositories.
    • user repository -- the portion of a server repository that belongs to one user.
    • replicated repository -- a repository that's a copy of a user repository.
    • repository -- the term "repository", when used without any qualifier, generally means a user repository, not a server repository
    • relay server -- For example, a departmental server running under the sys-admin's desk. If each person is replicating data from their personal repository to that relay server, is all the data going into a single repository that has aggregated data from multiple repositories, or does it get stored into multiple repositories on a single machine?

Use Cases

. When Use cases
DONE Canoga Agree on a meeting time and place with colleague(s)
DONE Canoga Send out invitation to a party/social event
DONE Canoga Share a task with requestor/requestee
DONE Canoga Share my contact info or someone else's contact info
DONE Canoga Collaborate on a note
DONE Canoga Share a calendar (e.g. Mitch shares his calendar with Esther including read/write permissions but with Freada with read-only permission)
DONE Canoga Publish an FYI calendar (e.g. KKIE interesting events)
DONE Canoga Self-managed time-off calendar for small companies
DONE Canoga Share an address book (e.g. company-wide phonebook)
Automatically 'unify' company address book with individual address book
Publish my contact (the ME contact) to all my friends
DONE Canoga View a group events calendar and subscribe to specific events
DONE Canoga View a common repository of shared documents for collaboration in a work group
DONE Canoga Assist with determining availability of a group
by showing free/busy calendar aggregation
via IM Agent assistance (For example, having an agent which would alert you if all the people you wanted to meet with were on IM.)
DONE Canoga Coordinate a list of shared tasks and events (i.e. mini-bugzilla e.g. Surprise party calendar or Potluck list)
CanogaWaitlist Schedule a group meeting
CanogaWaitlist Coordinate use of a shared resource (e.g. projector, rooms)
CanogaWaitlist Delegate a task (or conversely accept a task from someone else) i.e. let delegatee view the task delegator described
MOVED TO... Not In Scope No complex project management
MOVED TO... Not In Scope No complex collaboration on a shared document
MOVED TO... Not In Scope No group bulletin boards or newsgroups
MOVED TO... Not In Scope No threaded chat discussions
Open Issue Sharing code: agents or parcels
Open Issue Sharing user settings: e.g. spam filters, view layout settings
Open Issue Sharing schemas and semantics


  • Anatomy of a view. Sharing is done through views. In this context, we break views down into three components:
    • One or more Item Collections that the view contains. These can be explicit or rule based as described in Item Collections
    • The View Type. This is the type of UI Widget the view employs e.g. Table View, List View, Today View, Calendar View, etc.
    • View Type settings. These are the settings of a particular views -- specific columns, column widths, sort order, scroll offset, zoom level, etc.

  • What is shared? In all the key use cases listed above, what is shared is either
    1. an item collection and an associated recommended view type. Item collections are usually shared through a view using "Remote Browsing" as the initial sharing mechanism (as described below)
      • In general view type settings of the remote view are not shared. However, we need to go through key specific use cases to determine if there are special cases where we do want to share view type settings.
    2. a single Content Item. Single items are usually shared by sending it as an email. The item sent can be as a static item or a dynamic "hot-linked" item. Single items can also be shared when copying an item from a remotely browsed view to a local repository.
    3. aspects of view type settings. This is optional, but very frequent. The exact aspects to be shared is an [OI?]. We will be going through use cases to see if we can discern general principles.

  • Remote browsing
    • In remote browsing, a user receives a URL of a remote item collection (or set of item collections in a view). On navigating to this URL and with the appropriate permissions and correct authentication (see CanogaSecurityDesign), the user can browse the remote item collection specified by the URL, just as you would browse a remote web site. Remote browsing (as opposed to True Sharing) is a transient or short-lived sharing mechanism. Use cases include browsing a public event calendar or a vendor phone directory (you only view such items once or non periodically).
    • The remote Chandler client (where the remote item collection resides) must be up and running concurrently with the browsing Chandler client for this mechanism to work.
    • As in a web browser, none of the remote items in the Item Collection are persisted in the local repository. At most, they are kept for caching purposes. So, if the local Chandler client were to become offline, the remote view would no longer be accessible. Any cached items should only be valid for the current Chandler session.
    • If you have the right permissions, you can edit a remote item. However, private anotations can't be edited.

  • True Sharing
    • With True Sharing, proxy copies of remote content items are stored on the local repository persistently (not merely as a caching mechanism). Thus, after sharing, even if either Chandler client is offline, the local client still has access to these remote content items. It is a long-lived sharing mechansim (need not be re-initiated over multiple Chandler sessions). Changes are communicated asynchronously. This is the primary difference between Replication and Remote Browsing
    • True Sharing can be further subdivided into two sub-mechanisms:
      • True Sharing of Collections -- In this case, the unit of sharing is one or more item collections, together with a recommended view type. Changes in the composition of the item collections are automatically propagated. It is thus like remote-browsing, except that it can be viewed offline and across multiple sessions.
      • True Sharing of Individual Items -- In this case, the unit of sharing is a single content item. Example use cases are sharing the "me" contact, or subscribing a single event from a groups or public event calendar.


Sharing and Sending Chandler readable content items applies to both collections / views and items.

Sending universally readable data via email applies only to individual content items items.

Collections / view accept only known Chandler users.

Individual content items accept anyone.

Sharing and Sending collections / views and items have similar UIs. However unifying Sharing and Sending individual content items requires an extra step in order to integrate Sending universally readable data with Sharing and Sending Chandler readable content items.

Sharing and Sending individual content items can include non-Chandler users, but Sharing and Sending collections / views is reserved only for known Chandler users.

Users can always Send Chandler readable content items and collections / views to known Chandler users. Users can also try to Share content items and collections / views with any known Chandler users by appending an invitation to join the Sharer's Sharing Circle to the Share. If the recipient accepts the invitation, then the Share can proceed. If not, the recipient simply receives Chandler readable content items or collections / views. (See in-line workflow below.)

Chandler automatically sends updates to recipients who are in your Sharing Circle.

Sharers can push "Notifications" with a capital N to all recipients regardless of their Sharing Circle or Chandler status. Capital N Notifications provide Sharers with an affordance to PING recipients to when an important change has been made to an item. Recipients using Chandler clients see Chandler readable content items or collections / views. Recipients not using Chandler clients see nicely formatted email text.

  • 01_workflow_order.gif:

  • collections_views_v_items.gif:

For a discussion of how we reached these decisions, please visit: Sharing workflow decision history

Workflow proposals: Overarching principle

  • Staged levels of use Users don't see UI affordances for sending or sharing until they explicitly activate them
  1. Activate Send
  2. Simple, familiar affordances appear
  3. Activate Share
  4. More complex affordances appear
  • levels_of_use.gif:

Proposal for sharing a collection / view

  • Click the master "Share" button to initiate sharing (Caveat: This is just a stand-in visual for some kind of "initiate Sharing" UI affordance)
  • Following sharing affordances (attributes) appear
    • To:
    • Toggle blocks to set access priveleges: 1-time send, Read or Edit
    • Last updated column: Shows you when a particular contact in the To: field last received an update of the collection / view
    • Conversation item
    • Share button
  • Only Chandler users are allowed in the To: field
    • DnD contacts from Address Book (ie. auto-generated contact group of all "Sharing Circle" contacts or "Chandler" contacts)
    • Type in contacts
  • Default access level is: Read
  • Click Share
  • After 1 time, Share button turns to "Notify"

  • Managing "Notify" versions
  • "Last notified on..." is displayed near the "Notify" button
  • Chandler can auto-generate an ad-hoc collection of all past "Notify" versions. It would probably make sense to interleave "Notify" versions with any emails that are exchanged about the collection / view, creating one unified communication thread.
  • Similarly Chandler can auto-generate an ad-hoc collection of all notifications of changes made to the item, which would also INCLUDE all "Notify" versions
  • "Last changed by...on... See all changes" is displayed near the top of the detail view
  • [OI?] Are notifications content items?
    • MimiYin, 31 Mar 2004: "Notifications" with a capital "N" probably should be.
  • 041_sharing_collection_view.gif:

Tentative: Unified proposal for sharing and sending out an item

  • The first step applies to all items except for calendar events? (I'm not sure this is the right thing to do. It depends on the use cases.)
  • Click Send this item (Caveat: This is just a stand-in visual for some kind of "initiate Sending" UI affordance)
  • A note about terminology. We chose to use a different term for "passing around content items" from "sharing collections" because whereas users are always interacting with Chandler users when "sharing collections", they will sometimes be sending emails when "passing around content items." As a result, we need to have a word that represents the superset of email and sharing.
  • Sending affordances appear:
    • To:
    • Chandler users look different
    • Option to send updates of changes to users
    • Send button
  • Fill out To: field
  • Click send
  • Does a 1-time send of the item to recipients.
    • Sends Chandler readable content item to Chandler users
    • Sends nicely formatted text to non-Chandler users
      • ChaoLam, 31 Mar 2004: I think you'll have to send both of the above to all users. Only Chandler users can recognize the former
      • MimiYin, 31 Mar 2004: Yes this is just a representation of what the end-user will see. Chandler will do all kinds of things under the hood to make sure that the right users get the right information in the right format.

  • Resending items and managing sent versions
  • Send buttons turns to Resend
  • "Last sent on..." is displayed near the Resend button
  • Chandler can auto-generate an ad-hoc collection of all past "Sent" versions. It would probably make sense to interleave "Sent" versions with any emails that are exchanged about the item, creating one unified communication thread.
  • 043_sharing_item.gif:

Item sharing: Activating sharing affordances

  • Check the "Send updates of changes to Chandler users" option
  • Sharing affordances appear
    • Toggle buttons to set access privileges
    • Last updated column
    • Conversation item
  • Chandler users have an editable default setting of "R" (Read)
  • Non-chandler users have a NON-editable default setting of "1" (1-time send) [chao: debatable-> Non-Chandler user can become Chandler user at any time!]
  • Chandler users CAN have an editable setting of "1" as well
  • Click Send
    • Non-Chandler users get nicely formatted text
    • Chandler users either get a 1-time send
  • Send button turns to Notify after 1 st time. (This is Notify with a capital N. It's more like sending an email message than a notification. It overrides any settings the user may have for auto-dealing with notifications and essentially is a way for users to actively PING other users to "Notify" them of signification changes to an item.)

  • Managing "Notify" versions
  • "Last notified on..." is displayed near the "Notify" button
  • Chandler can auto-generate an ad-hoc collection of all past "Notify" versions. It would probably make sense to interleave "Notify" versions with any emails that are exchanged about the item, creating one unified communication thread.
  • Similarly Chandler can auto-generate an ad-hoc collection of all notifications of changes made to the item, which would also INCLUDE all "Notify" versions
  • "Last changed by...on... See all changes" is displayed near the top of the detail view
  • 044_sharing_item.gif:

What happens when users add recipients to an existing Send / Share?

  • Chandler shows "newly added" recipients to the To: field
  • Options: Resend / Notify 1) Organizer 2) All 3) New
  • update_new.gif:

What happens when a content item or collection / view is reshared?

What happens once the user hits send or share?

  • User sends out a JPG snapshot of the item/view/collection with a URL to remote browse.
  • Sharees click on the URL
  • If the Sharer is not online, the Sharee get's an error message
  • If the Sharer is online, the Sharee can view the item/view collection and has the option to "Subscribe"
  • [OI?] Can the Sharee remote browse more than once?
  • [OI?] What does remote browse mean in the context of items? Do users have to remote browse in order to view shared items?
  • 05_interacting_with_sharee.gif:

Secondary workflows

  • Remote browse has to look different from True Sharing
  • Sharer shares item B and C where item C is referred to item B
  • Sharee subscribes to item B, true sharing item B with Sharer. Sharee can click on item C from item B and go directly to the remote browse of item C.

Feature List

# When Feature Description
1 Canoga "Sending" items by email If I want to show you something, I can send it to you by email. If I send you email with a Chandler Item attached, your Chandler should "do the right thing" with the Item. What is "the right thing"? Does a copy of the Item live in your repository, or does my email merely have a link to the item in my repository? If you edit the Item, does my repository get updated? If I edit the item, does your repository get updated?
Here's the plan: In the e-mail we send a link, and as a fallback we also include a static copy of the item. The receiving Chandler uses the link to get a current version of the item, but if that doesn't work it still has the static one. At that point the person receiving the email can choose to Subscribe to the item if they want to.
2 Canoga browsing leads to true sharing True Sharing can be initiated from a remotely browsed view. When you're doing remote browsing, there should be some UI affordance to take a view and "subscribe" to the view (or the item collection shown in the view). Similarly, there should be some UI affordance to select a single content item in the remote view and then "subscribe" to this item, so that it will be truly shared.
3 Canoga Publishing for browsing vs. subscription From the point of view of the sharer, there is no difference between making something available for Remote Browsing vs. TrueSharing?.
4 Canoga Who can you share with? You can share things with:
  • A contact in your address book. (Or, more accurately, a specific Persona+ within a Contact.)
  • A group in your address book.
  • Documentation.PublicUser
  • A contact in an address book that you subscribe to. (Meaning, a contact which is in my repository because I have a subscription to it from someone else's repository.)
  • A group in an address book that I browse to. [OI]
    All of the above except PublicUser must be on my ListOfPeopleYouShareWith before I can share with them. See CanogaSharingCircleDesign.
5 Canoga What can you share? You can share:

* All the contents of a view -- for example, all the items in "Month View"

* All the items in some kind of category -- for example, everything in a project, a collection of Contacts, a list of e-mail addresses, your whole Email In Box, your work or home Calendars, a thread of Email messages, a collection of Tasks and Mail messages, a to-do list, all the results of some query, or an entire repository

* Individual content items like a note, task, calendar event, contact, or mail message

* You could also share your Calendar events for just this month, but only by first manually creating a view with a collection that included just these events.
6 Canoga Browsing known repositories You can browse or subscribe to things in repositories that are known to you. To get to a repository you need to be able to refer to the repository via a URL. You can navigate to a repository either by having it in your "Roster" ("Sharing Circle") or by explicitly typing in a URL. Your Roster ("Sharing Circle") has a set of contacts from your Contacts list. There is a "sharing address" attribute associated with a Contact (or Persona+)
7 Canoga Re-share via Dumb Copy It may be that there are items that you have permission to browse to, but which you do not have permission to re-share with someone else. If that's the case, you can always do a crude form of re-sharing by making a Dumb Copy of the item, and then sharing that copy.
8 Canoga Deletion of replicated items What happens when I delete one of my items that you had subscribed to? The answer is that the item will just dissappear from your repository. If you wanted to have a copy you need to have made a copy.
9 Canoga Clipping the edges of a shared item If I publish a Contact and you subscribe to it, what happens if that Contact is linked to other items which I don't have marked as public, and you don't have permission to see? For example, the contact item might be linked to the e-mail that the contact has sent me, or private notes. In this case, you will never even perceive that there was a link. In your repository, your local proxy version of Contact simply won't have some attributes, or won't have some values for some attributes.
10 Canoga References to replicated items Can task-1, a task I create, depend upon task-2, a task that's in my repository because I subscribed to it from your repository? Yes.
11 Canoga Query of a remote repository Can I query someone else's repository? Yes.
12 Canoga Local proxy copies When I subscribe to an item, my repository creates a local proxy for the item from your repository.
13 Canoga One "home" repository When you log into Chandler, do you log into a particular repository on a particular machine? Yes.
14 Canoga Automatic logins If your Chandler client accesses data from a bunch of servers, do you have to log into each and every server separately? No, this should be automatic.
15 Canoga Users own repositories A user always owns their own repository. The user can do whatever they want with their own repository, including deleting the whole thing.
16 Canoga Group repositories Can the Chemistry department have a single repository that is not owned by one user? Yes. For example, for shared group resources like a "Chemistry department document library" or a "Soccer team calendar", there can be a single repository that is not owned by any one user.
17 Never Server repositories Can an item live in a shared server repository without being owned by a single user -- for example, the Chemistry department server has a shared calendar, which doesn't 'belong' to any one user? No, each item was originally created by some user in their own repository.
18 Canoga Transport mechanisms Transport mechanism does not need to be secure in Canoga
19 Canoga Offline repository communication Support for asynchronous and store-and-forward communication between Chandler repositories
20 Canoga Chandler vs. non-Chandler clients We will create a separate component called a Chandler Sharing Network ("Sharing Circle" {OI}). Sharee's register to a sharer's Sharing Network ("Sharing Circle" {OI}). Once sharee is a member of the sharing network ("Sharing Circle" {OI}), they are automatically discerned to be a Chandler user and have the sharee will have the means to authenticate to the sharer. See CanogaSharingCircleDesign.
21 Canoga Private Setting All Content Items will have a "private" attribute. With the private attribute on, this item will never be shared, even if it belongs to a shared collection. This item can be mailed as an email attachment, but private items cannot be truly shared.
22 Canoga Sharing granularity In general, when you share a view, all of the content of the view will have the same access permissions (e.g. all "read only"). We won't have different permissions for different items. However, users may not want some attributes of an item to be shared. e.g. reminders in an Event or user annotations. Attributes can be marked as private at the Content Model per Kind-level, not on a per-item basis and not editable by the end-user
23 Canoga What links are shared implicitly? When an item is shared, and it points to other items, which of other items are also shared implicitly? This varies by Kind and should be specified in the Kind's Content Model. More details at ItemLinksAndSharing
24 Canoga Sharing with any contact I can give sharing permissions to another user before or after I know a "sharing address" for them. (The Sharer can set access privileges for "non" Chandler users before sending out an invitation to share, not just after Sharer and Sharee have established a "sharing network".)
25 Canoga sharing addresses A Chandler "sharing address" is not the same thing as a normal email address or jabber id.
26 Canoga Waitlist Automatic discovery of other Chandler clients We would also like to provide mechanisms to automatically discover other Chandler users (e.g. via ZeroConf/Rendezvous). It might be possible to automatically find out about other repositories on your subnet, if that's something that we can get for free from our underlying libraries. Would be a cool feature, but not something we're going to put much work into. We need to ascertain the cost to implementing this feature before committing it to the Canoga plan [@@@ Dev]. If we don't have this feature, the plan is that Chandler users will find each other's repositories in some out-of-band fashion (meaning they won't use Chandler to find each other, but instead they'll the telephone, or IM, or email to exchange the addresses of their chandler repositories. You can only browse or subscribe to things in repositories that are known to you. To get to a repository you need to be able to refer to the repository via a URL. You can navigate to a repository either by having it in your "Roster" ("Sharing Circle" {OI}) or by explicitly typing in a URL. Your Roster has a set of contacts from your Contacts list. There is a "sharing address" attribute on the Contact Kind. Move this to "SharingNetwork" ("Sharing Circle" {OI})
27 Canoga Waitlist Scheduling a meeting Collaboration activities that require consecutive actions from multiple users such as scheduling a meeting.
28 Post-Canoga Multi-user workflow Collaboration activities that require consecutive actions from multiple users such as scheduling a meeting or delegating a task.
29 Post-Canoga Searching remote repositories In the "fullness of time", users should be able to search in remote repositories almost as easily as local repositories.
30 Never References to browsed items Can task-3, a task I create, depend upon task-4, a task that I browse to in your repository? No.
31 Never Send items other than by email There is no way for me to send you an item other than by email. I can't use Chandler sharing features to "send" items -- I can't click on an item and tell Chandler to send it to you via some transport like Jabber or SOAP.
32 Never Query spanning multiple-repositories Can a query look for items in more than one repository? No. (No, except by using view groups, where each view group can come from a different repository.)
33 Never What can you share? You cannot share:
* new Kinds
* new Attributes
* a cool new MP3-player Capplet? (Capplet/Parcel/Context/Document)
* items representing an agent, a set of preferences settings, a list of permissions I gave out, a query expression itself, a view layout (my current "Month View" customized to with a certain layout, but with no content)
34 Never Clipping on a per-user basis You can't take a Calendar Event (or other item) and share it with person A and person B, such that you share some attributes with A but other attributes with B.

Open Issues

# Feature Description
1 Sharing views vs. sharing Item Collections Are views the primary affordance to enable remote browsing? If views are destroyed, will the sharing of the item collection be destroyed too? In the user's mind, are they sharing views, or sharing Item Collections? If I e-mail you a Chandler URL to my to-do list, does the URL specify just the item collection for the to-do list, or does it also include some mention of a view onto that to-do list? To be discussed in BuildingQueryViews?
2 "recommended view type" In remote browsing, what is being shared is a view's ItemCollection along with a recommended view type. I say "along with a recommended view type" because it is conceivable that the local client may not have the remote client's recommended view type. In this case, the local client can default to viewing the remote item collection in the Generic Viewer that is shipped with all Chandler clients.
3 no single item sharing Remote browsing only works with ItemCollections?, not single content items. But an item collection can contain just one content item.
4 push vs. pull In true sharing, should changes should pushed or polled? We should examine use cases further.
5 Transport mechanisms "Transport mechanism" refers to the specific high-level networking technologies used to facilitate sharing. While this is essentially an implementation issue, each form of transport imposes different constraints to sharing. We need to work with Dev to understand these constraints before proceeding further (@@@ Dev). We should also make sure that the user interactions amongst the final, small, finite set of transports we end up deploying are consistent. Transports that have been discussed in the past are SOAP or XML-RPC over HTTP, Jabber, or Email (for store and forward form of transport)
6 Sharing address vs. IM address Will we have a unified namespace for IM and sharing? Will your IM address be the same as your sharing address?
7 Sharing with a contact who has two Jabber IDs How do you share something with a Contact who has multiple Jabber IDs (e.g. home and work)? Do you select the contact, and then automatically share with both Jabber IDs? Or is there a way to select just one Jabber ID at a time, so that you grant sharing permissions to Jabber IDs, not Contacts?
8 Firewall issues How do we deal with firewall issues for sharing? Heikki to make recommendation
9 Schema customization What happens if two users customize the schema in different ways? For example, let's say I add a 'known since' attribute to all my Contacts, and then I share them with you. And meanwhile, you've added an 'books to suggest' attribute to all your Contacts. If you subscribe to some of my contacts, do you see my 'known since' attribute? Can you enter your own value for the 'known since' attribute? Or your own 'notes' in the notes field? When sharing, we should try to make some simplifying assumption -- either try to always share the union of the attributes from the two schemas, or try to always share the intersection of the attributes from the two schemas...
10 Calendar Design Doc Reconcile and rationalize this document with our Calendar Design Doc document
11 Calendar invitation via e-mail invitation without reply (sender sends an event as an e-mail attachment, recipient can drag that event onto their calendar)
12 Calendar scheduling via iTIP iTIP calendar invitation workflow -- back and forth exchange about when to schedule a meeting -- recipient accepts or counter-proposes, that information is transmitted back to the original sender
13 Calendar scheduling via iMIP iMIP calendar invitation workflow -- back and forth exchange about when to schedule a meeting -- recipient accepts or counter-proposes, that information is transmitted back to the original sender
14 view Calendar free/busy time meeting organizer can see free/busy time of the invitees
15 Calendar scheduling via Chandler sharing meeting organizer can create an event and publish it for replication via chandler sharing (as opposed to e-mail or iTip/iMip)
16 Chain Sharing Issue? Re-publish edit? Do we allow the chaining of shared items? Is this a special permission level? What are the implementation trade-offs? See Chain Sharing Issue?
17 Annotations We need to have a separate design meeting topic to deal with annotations (after capplet and sharing issues are resolved). How should sharing work for different sorts of annotations? When you publish an item as read-only, and I subscribe to it, what types of annotations can I then mark it up with? When you publish something with edit permission, and I subscribe to it and then make annotations, how do I specify which annotations are private and which are public? in general, which types of annotations are private, and which ones are shared, and which ones can be either private or shared? Annotations might be:
* a private note attached to an item
* a shared note attached to an item (e.g. directions to the meeting)
* marking an item as high priority
* a private categorization of an item (file this item in my Foo project, or in my Bar collection) -- Can my collections include items that I got by subscribing to things in your repository? Can a Group in my repository include a Contact I got by subscribing to the Contact from your repository? If so, are bi-directional reference still used? Does the Contact in your repository know that it's in my Group?
* a shared categorization of an item (file this in my workgroup's Baz project, or in our Biff collection)
* a "see also" link pointing from this item to another item, or vice versa -- Can an item in my repository have a "see also" link to an item that I got by subscribing to a collection in your repository?)
* adding an attribute to a contact
* a reminder, to go off 1 week before an event
For example, User1 and User2 are sharing a calendar event. User1 may want to have an alarm delivered 15 minutes in advance; User2 may want to have an alarm delivered 5 minutes in advance. I.e. obviously alarm settings are per-user, not shared. More precisely, alarm settings are per-user per-calendar item, since different alarms per meetiing are quite appropriate (e.g. to allow time to walk between buildings). -- use case care of AndyGlew (bottom line: reminders are always private -- they never propagate)
18 Where do items "live"? Is there always a single repository that holds the canonical copy of an item? Does an item "live" in a single repository? For example, does my address list "live" only in a Chandler database on my PC at home, even though it is replicated in other repositories?
Or, can many repositories all have perfect clones of an item, such that it is impossible to tell the clones from the original, so that the item really "lives" in more than one repository? For example, my address list "lives" in my Chandler database on my PC at home, and in my Chandler database on my PC at work?
When you subscribe to a Contact, are you really subscribing to that Contact just in the context of a single repository, or do you subscribe to that Contact whereever it might be? For example, let's say I browse your repository and subscribe to Contact A. Then you go off-line, but there's a copy of your repository on a relay server at work. Does my repository treat the Contact A on the relay server as being the same as the Contact A in your repository?
19 Schema evolution How do two users share items if one of the users has a newer version of Chandler in which the content model has evolved and has new or different Kinds and Attributes? What happens if I'm running Chandler 1.1 and you're running Chandler 1.0? If I publish an item, are you still allowed to edit it? If you publish an item, am I still allowed to edit it? We deferred this issue. In the course of my editing, do the item get upgraded to the 1.1 schema? To be revisited after 0.4.
20 Resolving two or more conflicts When a view or item is shared with two or more parties, all with read/write access, each party could make changes to the same attribute either at the same time or in a offlinne situation. How do we get back to a consistent state for this shared view or item? We should have UI to manually resolve conflicts. Mimi to design detailed workflow. Because conflicts can usually be automatically resolved at attribute-level and because of ItemConversation? affordance, we think this is a less important design issue
21 Share termination If a share has been terminated, what happens to existing shared items?
22 Item Remote Browsing Does remote browsing make sense for item sharing? What does it mean?


  • Action items from 01 Apr 2004 meeting (in brackets are action owner(s) and specific action if figured out):
    • Sharing transport (Lisa owns the issue, Chao and Lisa syncing up Monday)
    • What aspects of a view is shared and when are such changes sent out?
    • Notifications for sharing
      • Is the transport for notifications different from the regular sharing transport?
    • Sharing initiation (Mimi has a more worked out proposal above)
    • Sharing termination behavior (Design to work out use cases and requirements)
    • Sharing and Groups (Design & Heikki+Andi)
    • Re-sharing (re-share an item in a different collection) (Design)
    • References and edges of the cloud (Brian to work with engr and arrive at proposal)
    • Opportunistic synchronization & sharing circle
    • User identity (is this the same as opportunistic sync issue?)
    • End-user permission levels at attribute level (e.g. work and home for contacts)?
    • Lisa's naming use case: Can I make a new collection become an collection for sharing purposes? e.g. new "tempKorea" photo collection now wants to become "Korea" collection for sharing. Is this a Canoga use case? Should we solve "staging server" requirement rather than this specific feature request?

  • Unresolved 0.4 issues (as of 31 Mar 2004)
    • Sharing transport
    • What aspects of a view is shared and when are such changes sent out?
    • Notifications for sharing (invitations, changes, cancellations, etc.)
    • Sharing Circle workflow
  • meeting notes
    • ...
  • see also
    • ...

  • Mitch's notes from the design meeting on 6 April, 2004
    • separate out how we got here from what we're doing and why (in sharing). narrative needs high-level introduction.
    • sharing applies to collections and views
    • sending applies to items
    • two have similar UI's, but there is more of a push feel to sending
    • sending can include non-Chandler users, but sharing is only with people in Sharing circle
    • can send with updates to recipients who are in your sharing circle
    • can send notifications (with snapshot of current version) to all recipients


  • ChaoLam - 02 Jan 2004, 07 Jan 2004
  • BrianDouglasSkinner - 07 Jan 2004 to 28 Jan 2004, 24 Mar 2004

Comments Welcome

HeikkiToivonen - 13 Feb 2004 This is a place for posting comments. Anyone is welcome to contribute here, with any sort of comment smile

This may not be the correct place, but this is where I was sort of directed... Anyway, the issue I want clarification on is: how do we solve the problem of multiple people sharing a single machine (typical home setup)? There are several alternatives, in order of preference:

  1. Single Chandler application, one repository per user
    • This the typical model in other applications. For example, you only need a single Mozilla installation on a computer, but each user has (at least one, maybe more) profile which stores the personal preferences, history, etc.
    • One repository per user does not exclude several repositories for a user, but only one of them would be the active repository.
  2. Single Chandler application, single repository
    • Probably the most challenging to implement, and closest to Westwood requirements.
  3. One Chandler and repository per user
    • The installation would seem weird for Windows user's, because only one user could install in the default location of c:\Program Files.
  4. Only one user can have Chandler on any machine
    • We should not even consider this option.

In all cases the repository should reside in some other location than the installation. Security is perhaps the biggest reason for this. For example, on Windows you must be an administrator to be able to change anything under C:\Program Files. Linux and Mac have different directories but same principle. We do not need to require super-user rights in order to run Chandler. Additionally, by letting the user select where to place the repository they can put it on an encrypted disc while keeping Chandler application on a normal disc (maybe not the best of practice). Also since the respoitory is the piece you want to backup, it would help to place it separate from the installation.

There is also the question of Chandler extensions. If extensions will need to be written to the installation location, this would typically require administration rights. It would also be possible to have user specific extensions that would be stored to the same place as the repository (or maybe extensions themselves enter the repository?). Extensions in the installation location would be available to all users, while profile specific ones only to the user who installed them. Mozilla supports both kinds of extensions (although certain kinds of extensions are only possible in the Mozilla installation directory which requires administration rights).

MimiYin 22 Jun 2004: What constitutes a conflict?

2+ people replace the same attribute / attribute value with different attribute values. In other words, sharers are only in conflict if they are staring at the very same attribute value (ie. 5) and one person changes it to 6 and the other to 7. Sequential changes are not considered conflicts even if they arrive together when you sync.

What if we did away with this notion of conflicts? and simply tracked changes. Users can see all of the different values an attribute has had (similar to the way browsers remember the urls you've visited).

Use case If 3 people are trying to organize a meeting: Abe, Babe and Cabe. Abe proposes 6PM. Babe proposes 6:15PM and Cabe the consummate compromiser says how about 6:07:30PM? In the mental model of conflicts described above, if Babe and Cabe both edited Abe's suggestion of 6PM, their respective proposals of 6:15PM and 6:30PM would be treated as conflicts. If however, Cabe proposed 6:07:30PM only after he saw Babe's 6:15PM, then they would not be treated as conflicts. Well what about Abe? Does he really care to make the distinction? Or does he want to be alerted of both proposals. In fact, it might be downright mysterious for Abe to see 6:07:30PM without the context of Babe's 6:15PM proposal.

Proposal With the exception of edits to body text (which requires further, more in-depth thinking), perhaps we should simply preserve all changes (as yet unseen by the user) to attributes regardless of whether they're technically conflicts or not. What is the fallout of this?

Correcting typos would be treated as viable alternatives. (ie. Staten Island, sTATEN iSLAND, State Issland v. Kennebunkport) Could we auto-detect insignificant edits from significant edits?

  • Back_and_Forth.gif:
PageType HomePage
MaintainedBy none
PageStatus Work in progress -- this page is still being drafted?
CommentsWelcome Feel free to contribute comments?, either by adding to the Comments Welcome section of this page, or by posting to the dev list, or by sending mail directly to the person listed as maintaining the page.
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r78 < r77 < r76 < r75 < r74 | 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.