| # | 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. |
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:
