SHARING AND REPLICATION
We start with an observation about the design intent in Chandler in order to get to the basis of a discussion about implementation approaches.
The facility of sharing is meant to permit access to user-created content items (whether remotely browsed or truly shared)
We also need a way for a user to have Chandler on a home machine and a work machine and have "everything" on both machines, where the machines keep synchronized with each other. Let's call this facility "repository duplication" for the moment, to pick a term that is implementation neutral.
On this view, sharing could be implemented via a high-level protocol
(think WebDAV) operating above the repository, moving "capital-I" items (or item clouds) between Chandler instances and/or other conforming clients.
With respect to "repository duplication", what needs to be conveyed includes:
- all content items
- private parts of content items not usually shared with others, such as reminders
- various auxilliary data such as mail filters, email account info, agents, views, etc.
However, as use of the repository expands as more applications are developed, repository duplication grow to have other specific requirements which are not presently known or knowable.
It's natural to think that "repository duplication" could be implemented via low-level replication facilities built into the repository itself, which would have advantages in terms of performance and flexibility.
HOWEVER, PLEASE NOTE there is potential overlap between the implementation approaches of a high-level sharing protocol and repository replication, and therefore a need to make careful choices and for coordination in our approach.
So, for instance, if we implement small-k Kinds and large K-kinds to enable multiple "clouds" per kind, AND if we are careful in definitions, we could accomplish the greater degree of sharing necessary to meet the requirements for repository duplication using the high-level sharing protocol.
What's the right choice?
Would high-level sharing have sufficient performance vs. a more low-level approach?
It's not either/or; it could be both/and, especially if we decide it's a good idea to allow two different but equivalent representations, an "internal" and an "external". That choice has its own costs, but also benefits, which is something we have to examine.
- 10 Apr 2004