Allow bookmarks to apply to new versions of a title

[kelson42]

Bookmarks apply to a book: a specific ZIM file identified via its UUID. The problem is:

• When this book is updated (same title, but recenter version), then the user "looses" its bookmarks
• This a problem for Kiwix, but kind of even worse for custom apps

We need a way for the user to easily re-apply its bookmarks to the latest version of the title. This operation will be called the "bookmark reconciliation".

Reconciliation requirements:

• Should be fully transparent for the end-user
• Should need (almost) no code change for the Kiwix developer
• Ideally we should have kind of a system which is not data destructive and allows to track things

[kelson42]

I propose to do like following:

• We identify the same "title" over time using the ZIM metadata Name.
• In case we have multiple flavours of the same title, we should handle the complexity accordingly. I guess that if we have only a new version, whatever the flavour, we should migrate the bookmarks, but otherwise do the bookmark migration only for the same flavour.
• We should migrate bookmarks to the most recent ZIM files, not older version. This should be done AFAP (older files should be ignored)
• Each bookmark should store the ZIM name as well to allow the reconciliation, even if the original ZIM file is not available anymore (custom app scenario)
• Reconciliation should happen with new Library class method reconciliateBookmarks(source UUID, target UUID). Both arguments are optional. If none given, then apply to all dead bookmarks. If "source" specified, then apply to all bookmarks. If both "source" and "target" are available then migrate only between the two ZIM files.
• Reconciliation should not delete any bookmark, just create new bookmarks.

[kelson42]

@veloman-yunkan @mgautierfr Do you agree with the proposal, do you want to patch it?

[rgaudin]

This is a Book/Title/Book reconciliation proposal, not a bookmark one. If it only re-conciliates ZIM files, then the API should not mention bookmark.

Doing more bookmark-related operations (such as checking whether the bookmark path still exists and what not) would require ZIM file access so a very differently scoped API.

[kelson42]

This is a Book/Title/Book reconciliation proposal, not a bookmark one. If it only re-conciliates ZIM files, then the API should not mention bookmark.

Kind of agree! reconciliateBookmarks(source UUID, target UUID) still makes sense, but might be based on a reconciliateBooks(...) which would handle the smart part based on metadata. Would that be a better?

[rgaudin]

Exactly