View Single Post
Old 03-08-2016, 09:55 PM   #4
DavidTC
Connoisseur
DavidTC began at the beginning.
 
Posts: 77
Karma: 10
Join Date: Sep 2011
Device: Nook, Boox C67ML
Quote:
Offline means that CC must have its own copies of books and metadata, and the user must be able to trust that the information is in fact available offline.
It seems like it would be a trivial toggle to show all books vs. only local books.

Quote:
This isn't correct. You can easily filter on two things by long-pressing the first one then using the navigation to examine what is left. You can do arbitrary filtering using CC's search. Finally, you can sort most book list displays by one of Title, Authors, or Series.
Okay. Although I do note that you don't seem to be able to filter *twice*, although I guess you could just type it in, and additionally the listing and sorting is unconfigurable, unlik all the custom mods over in the main interface.

And that sorta proves my point. You're duplicating everything again in that interface, instead of just letting us use the real interface.

Quote:
Others have asked for a variant of this, specifically to be able to automatically update CC's database and book files with information from the cloud. I am still considering the idea. And yes, I know that isn't what you are asking for.
It sorta *is* what I'm asking for. I'm just not sure as to why it should be limited to 'books already on the device'.

Quote:
Because the majority of users don't want all their books on the device, and because that would require maintaining a connection to fetch the book files and covers.
I don't understand this objection. The book covers, yes, but that seems like an obvious fix of just having a placeholder image. (Which would seem to be a nice visual indicator the book isn't downloaded yet!)

And obviously they have to download the book to read the book. That's always true.

Quote:
And this is one reason why it is a total rewrite of CC. The existing wireless device connection and all of its support would have to change. Something equivalent but non-cloud would be necessary to transfer the metadata.db and book files, because *lots* of users do not have their library in the cloud. And so on.
Huh? Why do you think something non-cloud would be needed? Why would you transfer the metadata.db differently? How would any of my suggestion even *apply* if the library wasn't in the cloud?

Okay, I clearly am not explaining this correctly:

Upon connecting to the cloud, what *currently* happens is CC downloads metadata.db, and presents a listing. When users click 'Download', the ebook and cover image files are transferred, and a record is added to the internal CC database. (If I am wrong about any of this, please tell me.)

Here is what I am suggesting: Upon connecting to the cloud, CC downloads metadata.db and adds all those records to the internal CC database, or updates existing records, making the file path be a pointer back to the cloud (Or, in the case of a local 'cloud', just pointing at where they already exist.) Then the user can use all the existing stuff built into CC to locate whatever book they want, and download the book (and cover) when they want them.

I have no idea why you think this is a big rewrite. It really seems like almost all the code required here already exists in the CC code. CC can already downloads and parses metadata.db, and it already adds books records from that, and it already downloads book files and covers from the cloud.

The sole thing needed is 'What a second, I don't actually have this book yet, let me connect to the cloud and get it and the cover before I launch it.'.

Quote:
The number of weird interactions with the wireless device connection is enormous.
I thought this at first, but not really. From what I understand, Calibre *isn't* reading CC's interal database, but rather just getting a list of files, like it does with all other devices. So it doesn't really matter what's in the CC database.

The one cavet seems to be that CC needs to be smart enough to notice when it's being handed a book it already has a record for, but no file for, and change that existing record to point at the new file instead of adding a new record.

Quote:
There are lots of users who sync their entire library to CC using the wireless device connection. Some have in excess of 15,000 books.
Yes. I have 5000. The problem is not 'how long syncing takes', it is 'When I get new books, remember to track down all my ereaders, and connect them to Calibre, and make it send new books'. Or, alternately, try to locate that stuff in a completely different interface from the cloud.

Everyone who uses the cloud server wants to be able to access (in some way), all their books somewhere where they don't have Calibre with them. (Or they wouldn't use the cloud server, they'd just use a Calibre connection, or the Calibre server.)

Assuming that sort of user, there are, basically, several combinations possible devices they can have:
1) Devices with enough space that someone can put their entire library on them.
2) Devices without that much space, or a user who is unwilling to dedicate that space.
a) Devices have a permanent free (or very cheap) internet connection.
b) Devices that are metered.
c) Devices that only have wifi.

People who are 1a, 1b, or 1c have an ideal solution. They can put their library in a cloud or a local shared drive, and get something like Foldersync and tell that to run on a schedule, possibly only on wifi. Then hook up CC to that folder. (This, I believe, the entire point of a 'local cloud' folder, unless there's some subset of people manually copying calibre library folders to devices.) This is what I would do.

Except CC makes this strangely complicated and makes people 'download' books from the local storage into their library, instead of just importing everything. Change that, and suddenly everything works magically. Entire libraries would just *be* on our devices.

People who are 2a would also probably like CC to transparently present their entire library to them in one interface, and it doesn't matter to them if the book is already there or not, except it's going to take one second longer. I don't see any problem at all there, this makes things much better for them.

People who are 2b, right now, are in a poor situation right now. First, they browse to where it should be, and when it's not there they have to connect to the cloud, download the *entire* metadata.db (Mine is twenty megs.), and then browse to the file there, all to download a 100k book!

With my suggestion, all those records would be local (They'd have to connect to the cloud occasionally to get a new metadata.db, but much rarer, and could do that when they're on a non-metered connection.) And so they'd only having to pay when they download a book.

So that is five, out of six possible combinations, that would operate much better if the CC database would just fill itself from metadata.db.

People who are 2c...well, they might, in theory, get confused as to what is going on, when they have books show up that they cannot access at all. Like I said, a toggle to only show local books would fix that. And, here's an interesting problem, the way it is currently, they literally have no way to find out if they have a specific book or not in their library when they can't get on wifi.
DavidTC is offline   Reply With Quote