Links

• SharingAndReplication20030410
• IntrinsicIMAPIssues
• Andi's ItemCloudsAndPermissions20040409

Rendezvous vs. JXTA

• http://www.apple.com/macosx/features/rendezvous/
• How standard is it? "based" on IP... haha.
• Developer FAQ: http://developer.apple.com/macosx/rendezvous/
• Support on Windows and Linux too

Notes on replication

Our sharing protocol needs to know when two repositories are replications of each other. So if I share Mitch's calendar, I should be able to get updates of that calendar from either Mitch's work machine, or Mitch's home machine, if both those have Mitch's calendar.

These kinds of issues drive us to conclude that application semantics are involved in replication:

• Mitch and Andi pointed out that users can deal with conflicts on semantic items if Chandler asks them. E.g. the user can be told that an Appointment has been edited in two places, and which changes to pick. However, a user can't so easily handle low-level conflicts -- e.g. if a baseEmailAddress item linked into a number of contacts and emails has changed.
• Two replicated repositories might both connect to the same IMAP server -- e.g. my home and work machines. How do we allow both machines to download emails, and then find out which ones they've already got? How does a TODO note added to an email on one repository get replicated to the same email on the other repository?

Some application semantics (related to replication) can be defined in a schema. For example, an email content schema can indicate which things (attachments, links to contacts) are part of the "email" resource, and which aren't. However, we realize that in the limit, schemas aren't capable of expressing everything -- so at some point we have the ability to replace schema information with a simple callback.

FS API considerations from adding caching

From Disconnected Operation in a Distributed File System, James Jay Kistler

Experience from Coda indicates that the API used locally to access data objects should be designed with replication in mind. Coda took the Unix file system and AFS, and extended the local file-system to include client-side caches of remote data that the user accessed.

Transactions: the Code cache needed to infer what a transaction was since the Unix file system calls didn't include the notion of a transaction. Sometimes this inference worked but sometimes it didn't. Coda proposed a new Unix file-system access API that included transactions, with the idea that over time applications would migrate to the new API and caching/replication would work better.

Granularity of data object access: Coda found that conflicts would be reduced if data object access calls were made more granular. For example, Coda developers proposed breaking the calls that create a new binding in a directory and add new content to that binding (write new file) into two actions, one of which modifies the directory and the other doesn't.

-- LisaDusseault - 12 Apr 2004