View Single Post
Old 08-12-2012, 06:02 AM   #7
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: 11,741
Karma: 6997045
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by dwanthny View Post
I have no use case in mind. I was just going to see if it could connect and transfer books using my very long arms to control calibre at my house. I'm not interested enough to bother with remote access so I think I'll pass.
This brings up another question. Kovid mentioned that it would be nice somehow to start transfers from the device instead of from calibre. I can see how to do this technically, but the user interface parts are complicated. I can also see why people would want this. They have presumably figured out how to turn on the driver, and it would integrate very nicely with browsing the on-device book collection.

One way to do it would be using the to-come content server interface. You could browse your books using the same interface the app presents for books on the device (to the extent possible), select, and download books. We would support (somehow) an ondevice indication. The advantage of this solution is that the content server exists and is made for this purpose. The disadvantage is that the content server expects page-oriented fetches, where our UI really requires having all the information in hand before we display anything. We can of course have two UIs, but that is not an optimal solution.

Another way to do this would be to permit you to talk to calibre over the device interface instead of the content server. The problem I have is to decide how it works. It is easy to imagine adding the equivalent of calibre's "in library" to our UI -- some sort of checkmark on the display. The more interesting question is showing books that are in the library but not on the device. We would need to show both OnDevice and InLibrary, which isn't hard but will take some thought. However, do you see a list of *all* the books in your library? Does it support searching? Does our grouping interface work? Is any of this possible with reasonable performance?

I think we could make the performance reasonable if we limit the number of books we will show, and let you (force you, perhaps) to make a search to respect that limit. We would also probably be required to use a reduced metadata set such as title, author, tags, series; and no cover thumbnails. We certainly don't want to send full metadata for 20,000 books. The first problem is transfer time, and the second is local storage to manipulate the information.

Any thoughts? Would accessing calibre when connected as a device be useful? Or is the content server sufficient?
chaley is offline   Reply With Quote