Just giving it a try these days but long road ahead. I’ve many doubts on how to proceed with the module (…at this hour, even questions I’m unaware of how to formulate in my mind 
).
TL/DR:
- how to store properties for book libraries and handle paths collisions and naming of paths (which restrictions must be enforced).
- rpm packaging options, installation/update method and how to handle uninstallation.
- request for a working apache configuration to use calibre-server behind a reverse proxy from a subdirectory (
http(s)://domain.tld/calibre). Must allow user authentication, upload of ebooks and conversion of ebooks, being the latter the main problem. - What about user authentication?
- suggest default library name: now it’s the english word Books
- port number for the service: picking 8008 (http alternate) was a temporary choice due to default port clashing with one from onlyoffice/collabora module/howto, IIRC.
Haven’t thought yet nor done anything with users, and nothing on GUI side.
What is more or less done...
- db entries
- service (templated, as it requires parameters from db)
- apache virtual host template, via FQDN (…but reverse proxy to subdir not working); DNS record has to be set manually
- update/save events and conf action (evolving creatures)
- creation of a default library
- logrotate (untested)
- spec file able to build an rpm (but will need amendments)
Working on...
- script to add/disable libraries (left aside for now)
- samba share where to drop books to be automatically added to libraries via cron (not sure about using inotify). Great part of it based on the work done by @stephdl for transmission module.
The idea was to have one network share with directories on its root matching the directory name of each library, but…
Main doubt is about libraries of books in relation to nethserver db. Calibre Server is able to manage multiple libraries (though users might be used to have just one).
ATM I’ve a Libraries db property (config show calibre Libraries) with a single field containing absolute paths to the libraries, using ; as separator:
/var/lib/nethserver/calibre/libraries/Books;/var/lib/nethserver/calibre/libraries/New Library
That can be managed but isn’t very comfortable and prone to error. ATM only need absolute paths but, if need for more options arise, we could consider having something like this (even with more fields):
| LIBRARY_ID | LIBRARY_PATH | SAMBA_SHARE |
|---|---|---|
| MyBooks | /var/lib/nethserver/calibre/libraries/MyBooks | /mountpoint/MyBooks |
Here I can do with your suggestions…
- changing the way data is stored, maybe using library_key=calibre_type{propN=valueN}
- using json
- creating a separate db
- storing them in a regular text file
- et cetera
Was also thinking of having libraries with absolute paths and libraries that only specify the directory name:
- libraries stored in db without slashes
/(absolute path build from code later on):- Books
- Comics, magazines and whatever
- Ma bibliothèque personnelle
- libraries with absolute path (starting with
/):- /var/lib/nethserver/calibre/libraries/Comics
- /another/path/where/sysadmin/set/permissions/for/calibre/user
Other entries wouldn’t be processed.
Some possible issues: symbols and international characters, libraries with same directory name (Books, books, /path/to/other/Books) and samba share.
The idea was to let sysadmin:
- manually copy/upload existing calibre libraries registering them in the db for calibre-server to manage them.
- use libraries stored in other paths
- use provided or custom mounted samba share
- auto add books from samba share: shall books be removed once added to calibre? (samba share could have a trash bin)
If you expect them to cause issues comment on it. If some feature is superfluous it can be dropped. Forgetting about custom library paths and custom samba mountpoints would ease it significantly.
About RPM package(s) and Calibre installation… ATM the update event checks if calibre is installed. If it is not, goes online to download the upstream installer script and runs it (pre-compiled binaries). Kind of a sacrilege for packagers.
Other options would be to integrated the installer script inside the rpm OR use a calibre-installer.rpm OR build from sources as @mark_nl intended. First two options suppose less work and maintenance, third option would be the only one for packagers but requires more work and could lead to fight with the removal/replacement of multiple components (due to licensing, package separation…) to comply with the fedora/redhat guidelines.
Kindly expecting your ideas and suggestions. Even answers to unasked questions, from mind-readers out there. Time to sleep on it.
EDIT: forgot about https://github.com/kovidgoyal/build-calibre