Quote:
Originally Posted by kaufman
This is somewhat more work for you, but perhaps you can do it as a separate app that completely is controlled via IPC from CC. If a person tried to run it standalone it would just popup a message saying that it can't be run that way.
Another advantage of this is that you could leverage some of the searching/sorting capabilities of CC to add more functionality at little cost. So, for example, if you are grouping by a specific author in CC you could have a menu item to show all the other books by that author that are stored in the cloud (or even better all the books by that author that are not already part of the CC database). Executing that function would send a message (or however android handles IPC) to the the new app to actually get the list of matching books, which could then be shown in CC. And so on....
|
Actually, this is more work than option 1, adding cloud access directly to CC. First, the slave app would need to understand completely calibre's database so it could answer questions about anything CC can group on, an amount of work more-or-less equivalent to building a new DB layer into CC. In addition, CC would need to implement the client side of some protocol to ask the questions in the way you describe, and in addition implement the user interface to be able to formulate questions about books that share no metadata with the books in the current library (browsing the cloud).
My feeling is that you are objecting to the a second app (second UI etc), and are really arguing for option 1, implemented differently to deal with our objections to IAP. I can understand this position. Clearly the combination of CC's import and the second app is not as elegant as CC itself directly accessing the cloud. On the other hand, the combination offers more functionality because it is not tied to any N (for whatever N) cloud storage companies. On the third hand, the combination is more difficult to explain. and so on.