View Single Post
Old 08-22-2014, 12:13 PM   #83
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,476
Karma: 8025702
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by kaufman View Post
This would certainly be a workable solution for me. Perhaps a first step towards this would be to have CC change the way it stores the books to be the way Calibre does it on the computer (this would include the directory structure as well as the opf and cover files). Then the next step might be to scan for new files when requested and add them to your internal database. A last step might be to read the metadata.db file directory, But I am not convinced you ever need to do that.
Why change how CC stores data when syncing as a wireless device?

Almost all of your arguments have strongly implied (I think "required") that CC be able to read and process calibre's metadata.db. For CC that means a different DB layer that understands metadata.db instead of the current db. If it can do that then it is a very small step to using the rest of the library folder structure. After all, the paths to the books are in the db in both scenarios.

It is worth saying that replacing CC's data layer is an enormous amount of work. That is why option 1 is not attractive to me unless I can find a way to charge for it, etc etc as has been said many times in this discussion. Having the complete calibre library locally on the device would have to be a chargeable option, as would embedded cloud sync.

Of course, having IAB to charge for the above opens the door to having all four sync types be separately chargeable (wireless device, content server, local calibre library, cloud sync), but I think down that road lies perdition. We certainly can't take functionality away from current purchasers and we can't "fork" CC to have two apps. We can't use in-app flags because they are so easy to pirate, unless we just throw our hands up and admit that the slime buckets will defeat anything we do so it doesn't matter.

Another thing to deal with: having IAB for connection options reopens the free/pro question that we (hope we) just closed with the demo version of CC.
Quote:
You could then (if you wanted to) write an external program to grab the files from the cloud, but I am not convinced you would need to since programs like dropsync could do that for you. Some people would work that way, and others would just continue to do the wireless syncs.
Assuming that CC (or a variant of CC) could process calibre's db, then Dropsync would do everything needed. All that would be required is to have a consistent copy of calibre's library on the device.
chaley is offline   Reply With Quote