View Single Post
Old 04-08-2014, 12:47 PM   #10
chaley
Grand Sorcerer
chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.
 
Posts: 12,462
Karma: 8025600
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by kaufman View Post
What are your concerns about the second part being a good idea?

...

Having said that, why would you split this into two options? Couldn't you just have one update command if the metadata or the book has changed?
My concern is that send-on-metadata-change is not actually the best way to solve the user's problem, and in fact can create more problems than it solves. For example, what does "metadata changed" mean? In CC it means that the last mod date changed, which can happen when nothing changes in the metadata. One case: resetting the backup status. Another: manipulating a custom column's definition. A third: the date gets updated because the case of a tag changed. What we would immediately face is the need for some kind of criteria defining what the user considers to be important changes. That is the road to perdition.

Your question about splitting the two options is related. I actively do not want to resend books when metadata changes. I change metadata all the time for my own record keeping. I don't care if the metadata in the book is correct. I never look at it there, so resending the book is a waste of my time.

On the other hand, I have been known to run "polish" on a book to update the jacket (very infrequently, usually for my wife), or to reconvert the book to get better handling of scene breaks, spacing, or paragraph handling (rather more often). In this case the format itself has changed and I want the changes, which I know because I made them. Which leads to the "isn't the best way to solve the problem" assertion. If the user wants to change a book, the best place to do that is in calibre. There are so many tools to do so many things, some of which don't touch metadata. We got here by discussing one of them, the fanfiction downloader, which I think isn't required to change metadata. Triggering the refresh by a change in the format puts the process under the user's control while eliminating the need to remember to transfer the book at next connect. It is the "remembering" that is the real problem.

Bottom line: sending on format change is easier to explain, provides for user control over the update process, and doesn't create an immediate need for feature extension (the criteria).
chaley is offline   Reply With Quote