On May 21, 2012, at 18:33 , Harris Magner <harris.mag...@gmail.com> wrote:
> I agree with Christiaan that we shouldn't rely on just Apple's NSDocument > checking. It is nice in the sense that it alerts the user when the file he > tries to save has been changed on disk, but it does not help resolve the > conflict well. If I recall correctly, Christiaan's point is that because of Apple's NSDocument checking, you can't do anything further. You don't know which file it is supposed to point to when a change notification arrives, and the scenario may be different for atomic (safe) saving vs. a direct open/write. > Here is one such scenario: if I changed the main .bib file from computer B > (while my bibdesk on A was open), and I come back to A, make some change to > the main .bib file on A, and try to save, there is conflict, and Apple asks > me should I save or not. But there is no easier way to resolve that if I > don't want to lose changes made on B or A. Yes, that scenario is clear, and the way to solve it is to notify that the file has changed as soon as BibDesk is made active. > If Dropbox doesn't provide a good way to notify about a file change, what is > wrong with polling from Bibdesk to see if it has changed (as some one already > mentioned). Agreed that it is not efficient and elegant, but one can use > heuristics to make the polling efficient, for example: poll when Bibdesk is > in focus, or when the user attempts to make a change, etc. And make it > elegant when better file change notification support is available. File change notification via kqueue has been available for years, and it works well. The problem is figuring out which file to watch, and making sure it's consistent with Apple's behavior. Here's a problem to think about: 1) system A has foo.bib open in BibDesk 2) user renames foo.bib to bar.bib on system B, and it is synced with A 3) user then adds a reference to bar.bib on system B What should happen on system A? The original foo.bib is gone, replaced by bar.bib. Renaming in Finder on system A, that change would be tracked automatically; i.e., BibDesk would show "bar.bib" as the open file, as soon as you made it active. You have to balance user expectations, race conditions, and problems inherent in non-local filesystems when thinking about this. Using -[NSDocument _handleDocumentFileChanges:] is a possible (evil) option, but the work Apple had to do for iCloud and Versions make this so unattractive that it's not even funny (class-dump NSDocument in 10.7 or later to see what I mean). Even if BibDesk could support iCloud, it's apparently far from trivial: http://www.optshiftk.com/2011/12/slides-available-from-icloud-lessons-learned-talk-at-seattle-xcoders/ Maybe NSFileCoordinator could help, if Dropbox uses it, but you'd still be reinventing much of what Apple has done for iCloud...and it's not clear how well that works, from what I've read. In addition, it's only available on 10.7 and later. -- Adam ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
