When we started this whole My Dream App adventure, there was a stated goal that the ideas should take advantage of as many Leopard technologies as possible. At the time, we knew a little about Leopard, but since I for one was not a developer, there was really very little for me to go on. Jump forward a year, and Leopard is out (and installed on all of my systems), and all the NDA’s are lifted at long last. In that year very little was said about the applications under development for Leopard, thanks to Apple’s own embargo. Again, as I am not a developer, I was never privy to the specifics of those agreements, but nonetheless I was aware of their existence.
All that is water under the bridge now. Leopard is in the wild. The ADC has a full suite of Leopard developer notes. Ars Technica has even posted a magnificent breakdown of the core technologies at work. Reading all this material has given me pause for thought about how Portal will work and integrate into this new ecosystem.
Finder: File and Screen Sharing
The Macs on a local area network see each other much more easily now, and are much more talkative. It took very little time for me to set up file shares between my systems, so little in fact that I’ve stopped using DropCopy entirely. I have a standing link on each desktop to the drives in all my other machines, making file transfer insanely simple. The hardest part is deciding which files to send over, and, of course, dealing with conflicts. Screen sharing is another magnificent feature, and the “Back to My Mac” addition to .Mac is a powerful draw. The $99 price tag Portal was set to rally against has just gotten justifiable. I was even able to set up a screen sharing session with a Windows XP system in my house (the file sharing was one-click simple, the screen sharing was not. It took five-clicks).
The result is that machines on a network are all at your fingertips and the need for a file to be on your local system is diminished. Why sync your laptop with a bunch of files that just hog space on your hard drive, when you can just go “Back to My Mac” via the web from wherever you are? The only flaw in the argument is the issue of off-network access (the same flaw in the iPhone/Web Apps debate). The issue of “keeping two books” is also still present. Why do I want to risk having my iCal calendars on the laptop disagree with the desktop? With Leopard, .Mac becomes that much more powerful, much to the chagrin of Portal.
Time Machine, Spotlight, and FSEvents
I’m not a developer, and I’m not a computer science guy per se, so what I’m about to talk about may not be 100% technically correct. Just bear that in mind. Leopard has two headliner applications that take advantage of a low-level, system-wide event tracker called FSEvents. This API allows applications to track any and all file system activity, and it does so in such a way that the application that is doing the request doesn’t have to run all the time. Log files are created that keep track of all the events, so when an application comes online after being turned off for a while, it can take a quick look at the event history and know what’s changed about the system. Spotlight uses this to keep its search indexes up to date. Time Machine uses it to keep its backup directory up to date. Portal could use it to keep track of files that have gotten out of sync. The beauty of the FSEvents solution is that it is the user-level application doesn’t have to handle the task of looking for changes and tracking events. That sort of activity, which is potentially very time consuming, is handled by the OS itself.
The ideas I had a few days ago about Portal acting a lot like Time Machine were more prescient that I had thought. I had intended that Portal simply act like Time Machine in the sense that it was a tightly integrated System Preference that also had a full-screen “WOW-factor” interface. In truth, Portal would be well served if it could tap into the same system event tracker that Time Machine uses, and now it appears that such a thing is actually possible!
An added benefit of having a system-wide event tracker and backup system is that there is added pressure for high granularity in files. Massive databases are no longer practical in the post-Time Machine era since they take up unnecessarily large amounts of space (each change to a 50MB file means a completely new 50MB backup, even if the change only affected 50KB of real data). As granularity increases, so does the possibility of better and faster syncing. Apple has also taken to the use of XML in many application and file settings. Merging XML files is far from trivial, but it is a potentially simple file to read and to track changes in. This makes it possible to go in even tighter than the “per file” level for the syncs. This means less data needing to be sent between systems and more applications being candidates for syncing. Its a win-win situation for Portal.
Sync Services
Apple defines the “Five Phases of Sync” as:
Create a Sync Session (clients are alerted that a sync is coming),
Negotiate How You Will Sync (set modes for sync engine: fast, slow, etc),
Push Changes (either whole files or just the changes),
Resolve Changes (conflict resolution, either automatic or user-defined),
Pull Changes (all clients pull down the best file, after conflicts have been fixed).
Leopard is better suited than ever to communicate with other machines (both Mac and Windows), so setting up a Sync Session shouldn’t be difficult. Changes can be identified by calling on FSEvents, which will be running in the background on all Leopard machines (even without Time Machine turned on, Spotlight still uses the daemon). Conflicts can be resolved using the Unison framework, as has already been stated. Apple also includes a few handy services in their default Sync package for dealing with contacts, calendars, etc. that might be useful to integrate as well. The act of pushing and pulling the files from system to system could be handled by the OS and its handling of local servers (for standard file sharing, with the same privileges, etc), or it could be handled directly by the Unison layer. That sort of decision is entirely up to Martin, since I have no idea about how to do either one. (Martin, if I’m totally off base here, I apologize!)
The point I’m trying to make here is that all the pieces of the puzzle for a great syncing application are in place. Changes can be easily tracked. Conflicts can be handled by the OS for some cases (contacts, calendars, etc.), and by Unison in others. The Macs can all talk to each other very easily, so local networking won’t be an issue at all. I can even see it being possible to have Portal push itself out to all your machines so you only have to go through the installation process one time.
