MobileRead Forums - View Single Post

chaley · 04-27-2017, 07:48 AM

Unfortunately there are complications that argue against me trying to implement this.

Performance. I discovered when I did read and read-date syncing that it can have a significant negative impact on calibre's performance when connecting. One pays part of the penalty even when not syncing any fields.
CC User Interface. There are two ways of adding a synced column.
- Add another data field. This is what was done with Read and Read Date. Unfortunately going this route means I would need to add the new fields to the grouping drawer, sort menus, and "extra info" capability in the book list. This is a lot of work, easy to get wrong. It also introduces compatibility problems for backup and recovery.
- Use the calibre data field. Doing it this way avoids the grouping drawer etc changes, but it introduces the problem of overlapping change in CC and calibre. See below.
Managing change. There are (again) two ways to deal with overlapping changes to data in CC and calibre.
- Calibre always wins. This is what we have today.
- CC always wins. In this scenario, changes made in CC are moved to calibre. Changes made in calibre are lost when CC syncs. This method would be the easiest to build and explain, but it is probably unacceptable.
- The latest change wins. This means that calibre and CC must know where the data was changed, usually requiring a copy of the data or some other flag. This is what Read and Read Date do, and is probably the only acceptable implementation.
Given my son's current life situation, there isn't much chance of a feature like this getting into iOS CC any time soon. I am loath to make the apps more different than they already are.

There is also the question of "where does this stop?" Clearly people would like to change any metadata value in CC and have this propagate (sync) to calibre, but this isn't going to happen. If only some fields are synced, which ones?

Finally, version 3 of calibre's content server will (eventually) support editing metadata. Once this works then we have two possibilities for changing book metadata from a device.

The default: you open a web browser, go to calibre's content server, find the book, and change the metadata. It will show up in CC next time it syncs. This method requires no changes to CC, which from my point of view is very good.
An extension to CC's content server connection that exposes the calibre editing capabilities. This would be a lot of work, but it has the advantage of being a complete, build once, solution. Any fields editable in calibre's content server would be editable in this extension. We might also be able to implement an "auto-sync" where changes made by this interface are automatically written to CC's database.

Given all this, my answer is "we will wait and see." I want to know more about the new content server and its APIs before I do anything to CC's syncing.

04-27-2017, 07:48 AM	#5
chaley Grand Sorcerer Posts: 12,460 Karma: 8025600 Join Date: Jan 2010 Location: Notts, England Device: Kobo Libra 2	Unfortunately there are complications that argue against me trying to implement this. Performance. I discovered when I did read and read-date syncing that it can have a significant negative impact on calibre's performance when connecting. One pays part of the penalty even when not syncing any fields. CC User Interface. There are two ways of adding a synced column. Add another data field. This is what was done with Read and Read Date. Unfortunately going this route means I would need to add the new fields to the grouping drawer, sort menus, and "extra info" capability in the book list. This is a lot of work, easy to get wrong. It also introduces compatibility problems for backup and recovery. Use the calibre data field. Doing it this way avoids the grouping drawer etc changes, but it introduces the problem of overlapping change in CC and calibre. See below. Managing change. There are (again) two ways to deal with overlapping changes to data in CC and calibre. Calibre always wins. This is what we have today. CC always wins. In this scenario, changes made in CC are moved to calibre. Changes made in calibre are lost when CC syncs. This method would be the easiest to build and explain, but it is probably unacceptable. The latest change wins. This means that calibre and CC must know where the data was changed, usually requiring a copy of the data or some other flag. This is what Read and Read Date do, and is probably the only acceptable implementation. Given my son's current life situation, there isn't much chance of a feature like this getting into iOS CC any time soon. I am loath to make the apps more different than they already are. There is also the question of "where does this stop?" Clearly people would like to change any metadata value in CC and have this propagate (sync) to calibre, but this isn't going to happen. If only some fields are synced, which ones? Finally, version 3 of calibre's content server will (eventually) support editing metadata. Once this works then we have two possibilities for changing book metadata from a device. The default: you open a web browser, go to calibre's content server, find the book, and change the metadata. It will show up in CC next time it syncs. This method requires no changes to CC, which from my point of view is very good. An extension to CC's content server connection that exposes the calibre editing capabilities. This would be a lot of work, but it has the advantage of being a complete, build once, solution. Any fields editable in calibre's content server would be editable in this extension. We might also be able to implement an "auto-sync" where changes made by this interface are automatically written to CC's database. Given all this, my answer is "we will wait and see." I want to know more about the new content server and its APIs before I do anything to CC's syncing.