I’ve been eagerly awaiting the Developer Judges’ Comments since I found out that Portal would be moving on to the elimination rounds. Now I finally get to hear what they have to say, and get a chance to respond to their insights.
First off I’d like to clarify a few things brought up in Wil Shipley’s comments.
1) Where do you store the file so that the other machine can get to it? It has to be on a machine that’s accessible to both machines, which means you need a server somewhere, unless you want to force the user to bring the machines into physical contact to sync.
2) If you store this ‘master’ file on the net, you’d better have a darn good net connection, because lots of files that users typically use are several megabytes. Consider the average Photoshop or OmniGraffle document.
One of the core features of Portal is that users are “forced” to bring their machines into close proximity (all transfers are done by default across a Bonjour network). There would not be any third-party server storing the data (like with the .Mac Sync system), so a good net connection doesn’t enter into it. Portal is designed primarily for users with two Macs of their own, so they can keep their personal files in order on two systems.
3) Trying to do file syncing of an app’s data files without an app’s knowledge is tricky at best, because you could launch the application on a machine when the file on that machine is NOT in sync (imagine the network is down, or slow) and proceed to innocently make changes, not realizing you are changing an older version of the file.
Editing files that aren’t in sync is the situation I’m in now with my two Macs. Hopefully by having something like Portal to regularly re-sync my systems, I’ll cut down on this problem. Portal won’t eliminate this completely, but at the very least it would reduce the number of headaches.
4) If you do make changes to both versions of the file, there’s no way for “Portal” to know how to sync up the changes for EVERY type of app in the world. With Apple’s syncing, they have certain well-defined types of files and have a protocol for resolving conflicts in them. But they can’t resolve, say, two Photoshop files or even two text files.
This is a sticking problem for me too, but Portal’s path around it is simple. As smart as Portal may appear, it is still stupid when it comes to file merge: Portal always picks the most recent file. If both files Portal is trying to sync were modified since the last sync, then Portal might prompt the user to pick which one should overwrite the other (this would be turned off by default). I know this sort of overwriting is dangerous, which is why Portal should have a healthy dose of Time Machine integration to back up all files caught in this sort of quandary.
This method of file reconciliation isn’t the most brilliant, but its the sort of method I do now by hand. If Portal can automate even this crude method, I’d be happy. And at least its a step in the right direction. With enough user feedback, maybe Portal 7 might be really good at merging text files and halfway decent at merging Photoshop files!
This brings me to comments made by Gus Mueller:
Since file syncing is a very hard problem to solve (as we’ve seen over the years by the various attempts), my suggestion for Portal is to have a basic 1.0 with a solid foundation to grow from.
I’ve listed a lot of features in my blog posts, features that won’t all make it into a 1.0 release. Over specifying the app is my way of making sure that whatever shape Portal does take, it is the best it can be. I’d rather be held back by the reality of development than by my own imagination. If Portal 1.0 does even one tenth of what I’ve listed so far, I’d be happy beyond measure!!
