|
wow
wow -- i wasn't expecting such a vociferous (or supercilious) response!
I can't address all of the points raised, but I'll try to speak to some of the reasonable ones.
I use a number of different systems and pieces of software to interact with my various collections, and while they all play nicely with each other, Calibre is the exception. I can see how Calibre will work if you're prepared to allow it to take sole and complete control over your libraries (the "black-box" approach), but that's not what I want. I am well aware of the advantages of tagging systems and metadata systems (being a developer of [open-source] reference management software myself), but there is no reason why such a system needs to be tied to any particular file-system representation. This is an unnecessary limitation which seems to be hard-coded so deep into Calibre that it is close to impossible to extricate it. It would be far preferable that Calibre be agnostic with respect to the file-system representation (e.g. via a modular and customizable f/s backend).
In answer to the more tangential comments, of course I keep multiple backups of my systems and data (off-site, automated), and the issue with maintaining multiple copies has nothing to do with the cost of storage (do people really think in these terms? -- comments like this almost come across disingenuous).
Being a (primarily) python developer I am quite capable of working with the command-line tools, but I have no need to. My post is to record my opinion that with a little bit more flexibility Calibre would be a very nice addition to my own setup, but the insistence on either taking over my file system or duplicating it is obstructive and entirely unnecessary. I'm reading a lot here about ways to work around the issues this creates, and clearly these work-arounds are acceptable for most, but (and I quote), "for me its not worth the bother."
|