-
-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should we expose the bookName? #864
Comments
Having it appear on hover could be a good idea. |
I always was a bit disturbed by the bookName. (Without finding a solution for that). The thing is that
However, it is a nice way to display in the url (the only place where it is used) a nice, human friendly name. So it is, at best, a local/temporary identifier only.
I think we agree on this.
Can you be a bit clearer why it is important ? On |
This ticket is one year old 🎂 🎉 If you don't want to rely on the bundled reader, your still need the ZIM Name to construct a URL to the Note that since this ticket was created we changed the behavior of the So that very example is not valid anymore but since it's the identifier part of the URL, that's a non-API endpoint that users should be able to construct: to build a different homepage but link to the reader URL for instance. What I think:
|
IMHO It's time to implement it based on ZIM metadata. |
Following kiwix/kiwix-tools#586, it is clear that the bookName is an important information for Kiwix-serve users/integrators. While the v2 API is now completely reliant on UUIDs, reader endpoints like
/content
,/raw
,/search
,/suggest
and/viewer
are dependent on that bookName.bookName is a human-friendly book identifier in the internal catalog. It is built from the source ZIM filename, essentially normalizing it. On our public catalog, those mostly matches the
Name
metadata of the ZIM because that's our convention but it doesn't have to be.Given it's an identifier, I wonder if we should expose it in the OPDS API.
❯ curl https://library.kiwix.org/catalog/v2/entry/5f93c4a9-2ebd-ddd0-d13d-1edc29d511a6
The bookName is present inside the link to the reader
One could parse the link to extract the identifier but if it's a first-class input for our endpoints, maybe it deserves its own property?
It would prevent breaking access to it when changing our reader URLs but on the other end, despite its use, we don't want to consider it an identifier… just a pretty-URL-part
The text was updated successfully, but these errors were encountered: