File Coordination in Mac OS Lion
With Lion, Apple again did what it does best — solving problems that we've gotten used to working around for so long that we forget are problems.
But before that, it's interesting to quickly trace the evolution of file access. Initially, files were held captive to the machine they were stored on. Then came the cloud, as web apps, but it was a separate world by itself, so you had to choose between the cloud on one hand, and the convenience, power, and complexity of the filesystem on the other. Dropbox and its ilk unified the two to some extent, providing a filesystem and a web interface to the same data (and mobile apps, too).
Now Lion builds this into the system, and provides an API for apps to use, as opposed to Dropbox, which has to work with apps that don't use its API. That was necessary for Dropbox's success, for sure, but the more interesting question is: can do you better if you can get apps to use your sync APIs? Enter File Coordination, Autosave and Versions, new APIs in Lion. Here's how they provide a better user experience than Dropbox:
Documents are automatically saved to iCloud, and when iCloud changes are synced down, the document on screen automatically updates.
Files are autosaved periodically and when another app wants to access them. For example, when you drag a document to Mail, it's autosaved just before being attached.
Writes are atomic -- other apps don't see inconsistent state, as long as they use file coordination. This works for packages, too. (Packages are directories that are presented to the user as a single file, like a .app.)
Operations on giant directories are atomic as well, provided again that all apps accessing the directory use the file coordination API. If an app tries to move a directory that contains a file another app is reading or writing, it will wait for that app to finish whatever it's doing. Similarly, an app that wants to read or write something deep in a directory that's being deleted is asked to wait till the deletion finishes, so that it doesn't do a partial read, or write into a file that will be subsequently deleted.
When one app has a document open, other apps aren't allowed to write to it and overwrite the first app's changes. If the other app goes ahead and writes to it, because it's running on a different device, or because it doesn't use the file co-ordination APIs, the UI updates immediately. The latter is currently possible, with FSEvents, but far simpler with file coordination.
Apps handle open documents being renamed or moved. This is currently possible with file reference URLs, but many apps don't use them correctly. File coordination may make it easier for apps to do the right thing.
Versions snapshots files periodically so the user can easily go back in time.
When you have a conflict, the system informs your app of the conflict and lets it resolve it. After all, the app is in the best position to do so, because it understands its document format best. This is not possible in the Dropbox world.
When an app wants to resolve the conflict, that file access is prioritized below other writes, so the app merges the most up-to-date version.
It's interesting to see how much better you can do when you control the stack and can get apps to adopt your APIs.