View Single Post
Old 08-01-2011, 03:22 AM   #14
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,447
Karma: 8012886
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by Starson17 View Post
With Calibre's open source code and extensive SQL/Android access support already built in, this is an area that's ripe for someone to develop who is looking for a project, reads on Aldiko and has basic coding skills.
If someone is going to play, then beyond putting books directly into the library, something reasonably straight-forward, there are some interesting issues to work through.

First is deciding how to connect. My guess is that it should be done using 'connect to' instead of a device plugin, which would permit providing application connectors instead of device connectors. If we go down this route, I suspect that we might want to build a 'connect to' plugin architecture that integrates with device detection. Much of this is already there, used by (for example) Meme's kindle collections plugin, but we would need to extend the device drivers to permit the 'connect to' plugin to modify things like destination paths. Another way would be to have plugins that insert themselves into device driver plugins. I lean to the first because configuration will probably be very target-application specific.

Second is working through the collection management issues. It isn't clear to me how one supports arbitrary sortable collections such as exist for sonys without having to invent a new set of tweaks and parameters. It would also be best if collection management was bi-directional (something the sony driver does not do), permitting calibre to see changes made directly on the device. The interesting problem is determining what the changes actually mean and how to propagate them back into calibre's metadata. For example, if the user changes the name of a series collection, should that change the name of the series in calibre? If not, then what happens?

Third is reverse importing. What should calibre do when books appear in the device library that calibre has never seen? It might be that book matching is failing and calibre does have the book, or it might be that the book is genuinely new. The first case presents questions of metadata merging, and the second questions about auto-import.

The list can go on, but these are the ones that I have been musing about for the last year.
chaley is offline   Reply With Quote