In the beginning, Portal was born from a simple idea: Keep my two Macs in harmony. From the start, we all knew that Portal was a difficult idea, with a limited market (people with two or more Macs), and a nightmare of a development path. J Allard called it the “hardest problem chosen by the finalists.” Steve Wozniak said “there are tremendous challenges here… it seems that there isn’t an easy way to get multiple machines just to sync the simple stuff…” Jason Harris was the most direct: “Ease of Programming: low, Potential Earnings: moderate… Don’t vote for Portal…”
The need for a simple solution to this problem is well known, but how to get to such a solution is not. To that end, and in the hopes that Portal lives to fight another day, I submit the following Plan of Action.
Facing the totality of the synchronization problem is overly intimidating, so I suggest breaking the task into parts, ordered by necessity to a final, as yet unwritten application. This process can be best visualized as a three stage development: Foundation, Frameworks, and Finishing.
Foundation
As an application, Portal needs to first be installed on both systems, and then be granted permission to use the machine’s network interfaces to sniff out other Portal installations. Once they find each other, the two Portals need to connect in such a way as to facilitate file transfer between the systems, both for simple communication between the applications themselves and for the eventual transfer of the user’s files. Furthermore, each Portal app needs to be able to plug into the FSEvents system to be able to track file changes on their systems. For each file Portal is designated to sync, the app also needs to be able to identify the corresponding file on the other Mac so that it can identify conflicts. During a live connection between systems, file changes are automatically synced between the systems as they occur, so no dedicated “Sync Now” process is necessary. When systems connect after an extended period apart, the sync should launch automatically in the background.
Conflicts are the meat of the syncing problem, so lets pause for a moment on them. The zero-order, brute force solution would be to simply overwrite older files with newer ones. This is the option presented in the Mac OS X Finder whenever you try to add a file into a directory where a file with the same name already exists. For database driven applications, a partial merger is often available, such as when syncing a Contact or Calendar event from a portable device to a main system (like the iPhone to a Mac). These options should be available as appropriate within Portal’s conflict resolution system (see below). For safety purposes, older files should be backed up in either case (overwrite or merge), in case the network connection is lost in the middle of a transfer. My idea would be for all files to be moved to a temporary directory on the destination Mac first, then copied over the existing files later on. The file transfers should be checked for completeness and authenticity before the overwrite, and the older files should be moved to a safe location (either on the local drive, to a Time Machine backup, or elsewhere as designated by the user).
Network communication, file selection, file transfer, and file backup form the Foundation of a good syncing application and are the necessary first steps for Portal’s development.
Frameworks
The best way of handling conflicts is not at all clear cut. For some files, Apple has made the process simple (Sync Services), but for others you are left wanting. Thankfully, there are several independent initiatives working towards better solutions. Unison was the original favorite out of this category thanks to its robust feature set, but we shouldn’t stop there. To improve upon any one of these individual frameworks, Portal needs to take a “Best of Breed” approach to conflict resolution and use them all. The brute force overwrite method will be in place for all files and types at the beginning. Later on, specific improvements for a given file type (such as .HTML, .PLIST, .ICS, or .KEY) will be put in place on a case by case basis. If Unison is really good at DOCX mergers, but not so good at TXT, then Portal should limit Unison’s use to DOCX and find something else for TXT. Necessarily this complicates the mechanics of the conflict resolution and means that Portal will have a long development cycle. From a user point of view, the complications should be entirely hidden. From a developer point of view, one should realize that these improvements will be made incrementally and are not intended to all be ready for the 1.0 product. Version 1.0 is not the finish line!
Portal can move from a basic “smart file pusher” to a real, full featured syncing app by taking advantage of many of these existing frameworks (and improving them when possible).
Finishing
The last step is to hide all the difficult work done so far underneath a clean, simple user interface. John Casasanta said he’d “like it to be as simple as SuperDuper is at backing-up your computer.” J Allard said he’d “like to have seen less intrusive ui and for it to be directly integrated with os x“. I myself have started going in the direction of a “Time Machine”-like app where the core preferences are stored in a Preference Pane inside the System Preferences, and yet the app’s “main” user interface can be launched by a Dock icon. The goal is to make the act of syncing transparent and the process of conflict resolution quick and simple. The keyword here is subtlety. As much of the work as possible should be done in the background in such a way as to minimize visibility to the user (this means keeping processor usage down as well). When the user must be contacted, it must be in such a way as to minimize distraction from the user’s actual work. Popup boxes and dialogs should fade in and out quickly, information should be clearly presented, and the choice to be made should be explained properly. If the user wants to trust Portal to make all the decisions itself and have no user input whatsoever, that should be an option as well. If the file backups are robust, then this level of trust should be well warranted (possibly to the point of making it the default setting). File restore should be handled as efficiently as possible, taking cues from Time Machine (or even using Time Machine itself) when possible. The user shouldn’t have to learn an entirely new set of UI metaphors just for Portal.
If we let Apple dictate the user experience themes, then Portal can sink even further into the background and be that much more transparent. Extravagance and panache will be held in reserve for the occasional sync animations (user activated only, since the default background sync is invisible).
—-
In the end, Portal cannot be the end-all, be-all solution to the syncing dilemma. All Portal needs to do in order to be a success is be a solid 90% solution. (For the sake of the UI, that last 10% would be hidden anyway, so new additions wouldn’t even be visible to the typical user.) The Foundation level alone should get Portal to a 50% solution, with brute force overwrites as the ONLY “file merge” option. More options can come online with version updates. Integration into existing frameworks like Unison will also come later. All the while, the UI will evolve to match the new features, adding or removing controls as necessary.
