On Nov 11, 2011, at 17:21, M A wrote: > On Thu, Nov 10, 2011 at 3:41 PM, Christiaan Hofman <[email protected]> wrote: >> >> On Nov 10, 2011, at 22:21, Maxwell, Adam R wrote: >> >>> On Nov 10, 2011, at 13:03, Simon Spiegel wrote: >>> >>>> On 10.11.2011, at 21:03, M A wrote: >>>> >>>>> It's not really necessary to use iCloud for this. In fact, Dropbox is >>>>> already doing that job (keeping the bib files on different computers >>>>> in sync). What is needed is for BibDesk to notice when the bib file on >>>>> disk has changed and update to the version on the disk automatically. >>> >>> AFAICT Dropbox doesn't give you programmatic notice of file changes, so >>> BibDesk would have to poll for it. This is doable, but it's not a good >>> practice in general. It's a shame they can't just post a distributed >>> notification, at least. >>> > > Well, it does give notification to the OS (or so they claim) or > through Growl if it's installed. It seems like it should be possible > to hook into that somehow, though I don't know enough about what > Dropbox is doing to know how. > >>> >>> -- >>> Adam >> >> Based on my experience with automatic updating in Skim, I can say that I >> really don't like the idea. Even aside from the general problems involved in >> automatic updating, it's fighting against the frameworks, as they work >> behind our back in unpredictable way. So that's not gonna happen. >> > > I can understand this feeling, though it's not quite the same as in > latex where you're repeatedly regenerating the pdf. It's more about > giving the user the choice of which bib file to use once BibDesk gets > notified that the one on disk was changed. It doesn't seem like a good > idea to be able to set BibDesk to do this updating automatically. > Still, I'm not one to suggest that I know better than you how you (or > anyone) should use your (or their) time. I may like the idea, but I'm > not capable of doing the hard programming work. > > Mark A > >> Christiaan
It's not just about it being automatic (note we don't do that in Skim either.) It is also about the question when it changes, and how it changes, and more particular what "the" file is. This may at first sight seem like it's obvious, but it really isn't. There may not be a The One, there may be more. For instance, some tools replace a file as follows (and this is generally the safe way of doing it): move the old file aside, copy the replacement in its place, and delete the old file in its temporary location (or move it into the trash.) (This is safe because it allows moving the old file back when the updating somehow fails.) So now, which is "the file"? Is it the one that was moved and then deleted? Or the one that is replacing it at the old path? (This is related to the difference between file object and file name/path.) And when should I decide, and how should I know when I could decide? Note that an app that follows the file on disk would generally notice the change at the point when the old file was moved, but at that point the replacement does not even exist. But when I see the file being moved, I have no way of knowing that it was moved to be replaced in the future, it could just have been moved for moving's sake. The fact is that both answers are right, and both answers are also wrong. And the problem is that if we would assume one way, the frameworks (i.e. NSDocument) could assume the other way. And one thing that is most definitely wrong is for us and NSDocument to decide differently, that leads to real problems. However, we cannot predict what NSDocument will do, as this all happens in the private bowels of the frameworks that Apple does not reveal to us. Moreover, I can actually create situations where NSDocument does either of the two. Christiaan ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
