A Reply for the Celebrity and Tech Media Judges
This was the round of judging I was most looking forward too, with Leo Laporte, Kevin Rose, and what seemed like most of Macworld magazine on hand to offer critiques and pass judgement. And so, with a certain amount of joy/fear, I make my humble reply to their sage advice:
Leo Laporte (This Week in Tech) - Tech Media:
We’ve already got this with dot-mac, and even so, too few application developers support it. You think you can do a better job of corralling software vendors than Apple? You’ve spent way too much time on the eye candy, and way too little on the fundamental challenge of getting this to work at all.
Response: Portal will be able to sync applications even without any support from the developers, and I’ve been saying this from the start. I want AppZapper style search for the applications, so Portal can see all of the associated files. Exchanging those files here and there (and merging if at all possible) should do the trick for just about any setting that needs to be synced. If Portal detects an error, it pops up a warning, and if things go horribly wrong, Time Machine will be watching as well, so you can always step back in time to get a working copy. Until a developer says this sort of application syncing is unfeasible, I’m going to continue to run with it. And as far as “too few developers support it”, I totally agree, that’s why there needs to be a way to do syncing without every app having to be rewritten! Let Portal do a half-way decent job of it for v1.0, then get better with time. Even Apple itself doesn’t user its Sync Services in each and every app it produces, so why are we waiting for all the other companies to get around to adding syncing? We need to make a solution for ourselves, and for me, Portal is that solution. For more reading, see here, here, and here.
Martin Ott (SubEthaEdit) - Development Team:
A question which still seems to be unanswered is what’s happening if there are conflicting versions of the files you want to synchronize? That’s an important issue for every synching app. Do you have a master setup where files from the master automatically overwrite the files on the other machines? Do you want to ask the user in case of a conflict and on what type of information is she supposed to solve the conflict? Portal needs a convincing answer to this question.
Response: Now this question I’ve seen a number of times before, and I’ve tried to be consistent with my response: Portal 1.0 will be stupid when it comes to conflict resolution, so the newer file always overwrites the older one. This is the default setting, ignoring any file merge capabilities or any custom preferences for auto-renaming or auto-sorting. As Portal evolves as an application, real file merge can be added on a case by case basis, probably starting with XML merge, TXT or RTF merge, etc. Simple stuff compared to databases and Photoshop files. I’m no developer, but I believe Apple’s Sync Services brings something to the table here that Portal can exploit, namely that any app that already supports .Mac Sync will work perfectly in Portal (or at least as perfectly as it would with .Mac). This is a boost for Portal out of the door, because some apps will work great while the rest use the generic sync (AppMover style, the sloppy combination of AppZapper and Portal’s file syncing). Hopefully this will motivate some people, maybe just a few to begin with, to start adding in those Sync Services hooks. As Portal matures, its own generic app sync should get better as well, especially if it can train to work well with specific big names apps like Firefox. For more information, see the links at the end of the response to Leo.
The other judges were a bit more kind, so I’ll let them stand unanswered for a while, and post my response to them tomorrow. Now I’ve got to go to bed (its 1:25 am here)!
