On May 22, 2012, at 13:57, [email protected] wrote:
> Date: Tue, 22 May 2012 13:57:46 +0200 > From: Christiaan Hofman <[email protected]> > > 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 *If* NSDocument and the NSFilePresenter protocols both look at the world in the same way, then one way to track which file the NSDocument points to might be to implement the NSFilePresenter protocol presentedItemDidMoveToURL: method. The *If* could only be determined empirically through testing. However, even if that or some other mechanism was available to see how NSDocument tracks the file, then there would still be the problem of how you would track a file (that was open on to Macs) being moved from one location to another. In that case you have another black box in what Dropbox does. You could jump through a lot of hoops with the web API, but in the end that probably wouldn't work 100%. iCloud seems to solve this problem keeping the user from doing anything with the files outside the control of the API. In a Dropbox syncing situation, I think the best solution would be simply to tell users that syncing isn't supported for files that they move around while one or more copies of BibDesk is open. My main BibDesk library hasn't been moved in years, so to me and probably a large fraction of other users, this is probably a reasonable compromise. If that design compromise isn't acceptable, then I would agree that there's currently no solution. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
