On May 22, 2012, at 13:38, Colin A. Smith wrote: >> 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
I think all of this is irrelevant, which has been explained on this thread (by me, and also Adam.) The problem is NOT the coding time or the availability of methods to track files. The problem is systematic and is just that the framework is a black box. So let me repeat the central problem. There are two meanings to what a file is: the file object (node ID) and the file location (path). Usually they're pointing to the same thing, but sometimes they're not (e.g. when a file is renamed or deleted/replaced.) NSDocument internally tracks both the file object and the path, but they're completely unclear as to which takes precedence when. When a conflict between the two arises, it picks one or the other (sometimes one, sometimes the other, probably), but at exactly what point in time is completely unclear, it's most certainly not immediate and delayed. The problem if we would track the file in any way, we would certainly meet situations where the "file" we track is different from the "file" NSDocument tracks. No matter HOW we track or WHAT we track. And this is simply unacceptable. So the problem is that NSDocument is completely non-transparent in how it tracks the file. That's why I always repeat that it's Apple that has to provide the file tracking transparently (like with a hook in the NSDocument API), we simply cannot do it. Christiaan ------------------------------------------------------------------------------ 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
