This is a very interesting idea, but I'd take a reactive approach instead of the preemptive one you seem to suggest in the post. The reason for that is that:
<ol>
<li>Dropbox supports versioning</li>
<li>Hopefully more applications will not create conflicts than vice-versa (nb: this assumption might be wrong through)</li>
</ol>
My plan would be:
<ol>
<li>create a folder action to watch for conflict files</li>
<li>based on the parent directory determine the application</li>
<li>trigger a osascript quit event to both applications
3.1 if one application is the front one then you might choose not to sent the quit event</li>
<li>if possible the quit event should have a timeout (for the save scenario)
4.1 if the quit event times out then a message would popup to close the application manually due to the conflict</li>
</ol>
I'm not sure this would work out or if all the above steps are possible.
Alex://
Dropbox is such a tricky thing. I wanted to store active Scrivener projects there, but based on what I've learned from them this isn't recommended at all since Scriv writes so much to disk so often that Dropbox might corrupt the file.
I've had mixed results using Dropbox syncing with Scrivener too ... I think it comes down to an essential problem: how often Dropbox syncs and how often an app writes things to disk.
If you're going to modify the application bundle anyway, you could run this without using SSH by keeping a host-specific "active" and "kill" file on Dropbox, which is a text file containing a list of active programs and programs to be killed. Whenever an application is launched, it checks the other host's "active" lists to see if that program is running. If so, the program is moved to the respective host's "kill" list and the script pauses. Each host watches it's own "kill" list for changes and kills any programs whose name is moved onto that list. Once the program is killed, its name is removed from the kill list. The paused script sees this and now allows the program to load.
I realize this is a bit of synchronization (and, thus, waiting), but unless you're rapidly jumping between computers, it's only the "kill" synchronization and program shutdown (which you have to wait for regardless of method) that you have to allow to finish. Using only Dropbox has the advantage that it works in situations where SSH isn't possible, such as when VPN is required.
One problem with with this scheme, regardless of whether using SSH or the Dropbox method, is that sometimes one or both computers is offline and synchronization conflicts result. I've synchronized a number of folders in ~/Library and my solution to this is to have a regular script which crawls the appropriate Dropbox directory and deletes them. Program preferences aren't that critical and don't change THAT much for me to mind.
I had seriously considered the trigger file approach. I actually don't remember why I dropped it, but I think it was just the latency issues. Ultimately, you face the same problem as the major one in the post, though, where any script will hang if a save dialog pops up.
I think the simplest solution for either approach is to run something like ForeverSave for apps that don't already have autosaving built in (Lion or otherwise).
Agreed--latency would be the issue with trigger files, but I foresee save dialogs being the biggest sticking point as a significant number of the programs I use aren't Lion-ized yet.
Issues aside, this is an interesting problem and I suspect many of us have spent time thinking about it. I mirror my setup between a Mac Pro and a MacBook Pro using a combination of Dropbox for preference files/shell history/ browsing history and both Unison for my giant research directory and Synk Pro for files which have xattrs, etc. not handled by Unison. This setup requires some care and feeding, but it works really well. Someday, I hope this task will require less tinkering.
Remarkbox