> Date: Mon, 21 May 2012 21:33:15 -0400 > From: Harris Magner <harris.mag...@gmail.com> > > 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. 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. > > 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. > > Harris > > PS. The thread is old, but I think the discussion didn't reach any > conclusion, so my attempt to revive it.
(The following is perhaps better suited for the developer list, but the thread was started here so...) I've done a bit of thinking about the problem as it relates to a port of iOS to BibDesk I did some initial work on a few months ago: http://sourceforge.net/mailarchive/forum.php?thread_name=E50EDC5C-2D64-4758-90D7-F61D7D26E0AD%40colinsmith.org&forum_name=bibdesk-develop Regarding notification of on-disk changes, which Dropbox would trigger, there are a number of APIs to choose from including file system events, kernel queues, and the NSFilePresenter protocol: http://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/FSEvents_ProgGuide/Introduction/Introduction.html http://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/FSEvents_ProgGuide/KernelQueues/KernelQueues.html http://developer.apple.com/library/mac/#documentation/Foundation/Reference/NSFilePresenter_protocol/Reference/Reference.html NSFilePresenter provides a nice Objective C interface, but it is only supported on 10.7 and wouldn't detect the additional files that Dropbox makes when it has a syncing conflict: https://www.dropbox.com/help/36 There are MIT licensed wrappers already written for the other two APIs: http://stuconnolly.com/projects/code/ http://zathras.de/angelweb/sourcecode.htm#UKKQueue As for resolving conflicts after they have been detected, the important things to handle would be the usual record modifications, additions, and deletions. To do so robustly, I think you would need to associate some sort of unique ID (like a UUID) with each publication entry. There would probably also need to be a log written to the file to remember which records were deleted, to make sure deleted entries don't reappear after syncing. Finally, simultaneous modification of two records would have to either be resolved manually or through some sort of UI. Static and smart groups would be another can of worms. That's a lot of work, so unless there's some especially enterprising developer out there, perhaps the answer still is, "So that's not gonna happen." Cheers. -Colin ------------------------------------------------------------------------------ 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
