[chaley]

Originally Posted by Bari10

Ok, thanks for the conversation. Maybe I've misunderstood the likely direction of travel of Calibre Companion (and maybe Calibre itself).

On https://play.google.com/store/apps/d...calibreandroid I read:
"The first application: Calibre Companion supports connecting to calibre over WiFi and be detected by calibre as a device.
...
- Calibre Companion can update the metadata for the books on every connect, ensuring the information is up to date."

This does not sound to me as if "the device is totally passive" as you say.

In this case calibre is sending metadata to the device, "ensuring the information [on the device] is up to date". The device plays almost no role in this other than to conform to the protocol and operation sequence that calibre requires. I can assure you of this, as I wrote the code on both sides of the connection (calibre and CC) for this process.

I assumed it was indicative of the likely kinds capabilities that Calibre Companion might develop. Also, the command line capabilities of Calibre (http://manual.calibre-ebook.com/cli/...ented-commands) show that Calibre can add books to its library, convert books between formats and do other things, all without the GUI running - so why couldn't a device activate such processes, as I gather it can already (via Calibre Companion) alter metadata on the server?

Of course it "can". It is just simple matter of programming. Unfortunately, calibre's current device architecture precludes this.

This is all pretty standard client-server thinking: there is no "rule" that says that all activities carried out on a server have to be initiated by a GUI running on the server.

You are correct, and if calibre had a client/server architecture than we could do what you suggest. Developing a C/S model for caliber is a long-running background project that will produce results eventually, but we are not there today.

And as the Calibre content server already shows, devices can initiate useful interactions such as downloading a version of a book.

You won't get any argument about that. It would be very nice to have a full calibre client available my devices, along with everything that implies (simultaneous read/write, single database, single library, etc). However, and at the risk of beating a dead horse, the current calibre architecture doesn't support it.

Last point (this time around): starting up the Calibre content server can be done (via command line) without running the GUI. So can adding a book to the library. Why shouldn't it be possible to start the wireless device connection (to the library) without having the GUI running, and initiate transfers, conversions and so on? I gather from you that "the device subsystem is part of the GUI", which I hadn't appreciated - but I don't see that has to be so.

No, it doesn't have to be so, but it is so. The amount of work to change to a CS model is enormous. Couple that with the fact that there aren't very many of us working on calibre and all of us have higher priorities, and the work doesn't move along quickly.

Kovid has built the framework for the server side (a server-based DB). I am sure he would be delighted if you or any one else decided to finish it, or even move it along. Once that is reliable, then the work would begin to separate the gui and the command line tools into a "client", with a well-defined and enforced interface to the server. I know a fair amount about calibre's code, and the biggest problem here is data integrity and transaction validation, determining how to detect that the data held by the client does not match what is currently held by the server and recovering from it. Once that is done, then other clients can be considered, such as smart devices, ajax/html5, etc.