And I fully concur with Christiaan. Besides it is not worth the trouble as I 
also have written earlier on.  I have developed a technique to sync between my 
iPad and my Mac and I am happy with this. I wrote the needed AppleScripts (free 
to use by everyone, http://www.sysecol.ethz.ch/people/afischli Link Software) 
and I did not need any extensions of BibDesk.

Regards,
Andreas


ETH Zurich
Prof. Dr. Andreas Fischlin
Systems Ecology - Institute of Integrative Biology
CHN E 21.1
Universitaetstrasse 16
8092 Zurich
SWITZERLAND

[email protected]<mailto:[email protected]>
www.sysecol.ethz.ch<http://www.sysecol.ethz.ch>

+41 44 633-6090 phone
+41 44 633-1136 fax
+41 79 595-4050 mobile

             Make it as simple as possible, but distrust it!
________________________________________________________________________







On 22/05/2012, at 13:57 , Christiaan Hofman wrote:


On May 22, 2012, at 13:38, Colin A. Smith wrote:

Date: Mon, 21 May 2012 21:33:15 -0400
From: Harris Magner <[email protected]<mailto:[email protected]>>

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
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/bibdesk-users


------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

Reply via email to