-
-
Notifications
You must be signed in to change notification settings - Fork 55
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
Opds categories feed #492
Opds categories feed #492
Conversation
e5ce43c
to
e65d629
Compare
Codecov Report
@@ Coverage Diff @@
## master #492 +/- ##
==========================================
+ Coverage 64.60% 65.03% +0.43%
==========================================
Files 50 51 +1
Lines 3551 3627 +76
Branches 1801 1824 +23
==========================================
+ Hits 2294 2359 +65
- Misses 1255 1266 +11
Partials 2 2
Continue to review full report at Codecov.
|
7a78eb8
to
cdeff96
Compare
6893ca6
to
e6453d3
Compare
e6453d3
to
dfa385d
Compare
dfa385d
to
443af19
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OPDSDumper is not utilized. mustache was used instead.
I dislike the idea. Now we have two ways to generate opds feed.
I'm not against using mustache, but it would be better to port OPDSDumper to mustache and use OPDSDumper everywhere.
(And having a specific OPDSDumper class would allow us to test it without creating a instance of the server)
/catalog/v2/entries: an equivalent of both /catalog/root.xml and /catalog/search of the old OPDS API.
With issue #209 the plan is to move to a partial feed for the entries.
In this PR, the entries feed is a complete acquisition feed.
It is not a blocker for this PR, it is probably better to do it in two PR.
But we must care to not do a release with a complete acquisition feed.
Also, now we have only one url for listing all entries and search for them. I don't know if it is good thing or not, but I prefer to mention it explicitly.
If we change the URL paths/schemas we need to be careful. We have Kiwix Desktop and Kiwix iOS relying on them! |
We don't change the paths/schemas, we add new ones ( |
I moved most of the new code into |
443af19
to
4cc3fbf
Compare
New commits start from /catalog/v2/entries going through OPDSDumper |
The ideas is not to "have a OPDSDumper" but to avoid having two different implementations to do the same thing (transform a list of books, with some metadata, to a opds stream). |
c1ec1ae
to
52347dc
Compare
Done |
This pull request has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions. |
@veloman-yunkan @mgautierfr This PR is key and need review and rebase. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two small commenst on the code to fix and we are good. This is far better with all the code in the rendered and using mustache everywhere.
On a more general comment, #209 implies that the root/search feed is partial and then we get the full information doing another request (and so another endpoint).
We will definitively not do it in this PR. But I would like to mention that the v2 API may change in close future and client should not start to use it right now.
(And to have a more stable API, we may move the endpoint /catalog/v2/entries
to /catalog/v2/search
(and so keep entry
/entries
for the endpoint to get all information about entries)
const auto bookData = getBookData(library, bookIds); | ||
const kainjow::mustache::object template_data{ | ||
{"date", gen_date_str()}, | ||
{"root", rootLocation}, | ||
{"feed_id", gen_uuid(libraryId + "/catalog/search?"+query)}, | ||
{"filter", query.empty() ? MustacheData(false) : MustacheData(query)}, | ||
{"totalResults", to_string(m_totalResults)}, | ||
{"startIndex", to_string(m_startIndex)}, | ||
{"itemsPerPage", to_string(m_count)}, | ||
{"books", bookData } | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that this data is pretty closed from the ones used in dumpOPDSFeedV2
.
Could be have "only one method" using two different templates ?
(Or maybe even better, one template with just the endpoint changing ? If possible)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's consider that after the new API is finalized. I don't want the old API to be a drag on the new API, and a premature attempt to share code between them will do just that.
The new negative test-point demonstrates that Kiwix server doesn't distinguish /catalogBLABLABLA from /catalog.
Also removed an unneeded namespace qualifier.
We are good. Please rebase-fixup and we can merge. |
Note: no unit test added
Under Ubuntu 16.04/xenial, ccache seems to have issues with multiline raw string literals used inside macros.
The new field is intended to serve as a seed for generating semi-stable OPDS feed ids that only need to change when the library is updated.
/catalog/v2/entries is intended to play the combined role of /catalog/root.xml and /catalog/search of the old OPDS API. Currently, the latter role is not yet implemented. Implementation note: instead of tweaking and reusing `OPDSDumper::dumpOPDSFeed()`, the generation of the OPDS feed is done via `mustache` and a new template `static/catalog_v2_entries.xml`.
Reordered several statements so that the next couple of commits are a little simpler.
OPDSDumper sensed threats to its job security, so it lobbied to be involved in handling the /catalog/v2 endpoints, too.
This changes the output of `/catalog/search` as follows: - Entire search query (rather than only the value of the `q` parameter) is put in the <title> node. - Search performed with an empty query presents itself as "All zims". - The feed id remains stable for identical searches on the same library.
b5d31d8
to
78083f1
Compare
Done |
Will fix #518
This PR introduces a new OPDS API at
/catalog/v2
(as well as fixes a few noticed issues unrelated to that enhancement).Currently available endpoints are:
/catalog/v2/root.xml
: top level navigation feed, pointing to the full acquisition feed and to the list of categories/catalog/v2/entries
: an equivalent of both/catalog/root.xml
and/catalog/search
of the old OPDS API./vatalog/v2/categories
: a navigation feed containing an entry for each category with a link to the corresponding acquisition feed filtered by that category.Notes:
OPDSDumper
is not utilized.mustache
was used instead.