-
-
Notifications
You must be signed in to change notification settings - Fork 86
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
Remove OPDS "notag" parameter #440
Comments
"notag" argument of a query on the opds service is independent of how we implement the library database (xml, xapian or whatever). The "notag" query is used in kiwix-desktop to get the "other" category. |
@mgautierfr Thx for clarifying the usage of
|
@veloman-yunkan Can we move on with this ticket? Maybe we can keep the "notag" parameter for a bit of time to keep backward compatibility, but behind the scene this should work with XAPIAN operators. |
@kelson42 I propose to open a new ticket for utilizing Xapian for all other book fields too (currently, only title and description are indexed). This ticket can be closed together with that one. |
kiwix/libkiwix#484 was opened as proposed above |
@veloman-yunkan my bad, forgotten about your comment. perfect. |
@veloman-yunkan kiwix/libkiwix#484 and #318 have been implemented but it seems that the |
@kelson42 Preserving only two
(the value of the However the |
I somehow disagree with the idea of exposing the xapian request format in the API. Xapian is a implementation details. Filtering was made without xapian before and it may change in the future. We must define a search API and provide it to the user/client. If we use xapian internally, we have will have to transform the search query (from our API) to a xapian query. If we decide to use something else, the API will not change. |
@mgautierfr OK in principle, but pragmaticaly, this seems not realistic. I don't want us to mockup/reimplement somehow the full operator parsing... and we need these operators right? |
I don't know if we need them. It would be good to define what we need to support first. The OPDS stream is mainly used by clients (program) to know the list of available zim and (potentially) filter them to display subset to the user.
On the OPDS side, we apply filtering on xapian request ( We extend the search parameters with kiwix/libkiwix#459 and provide a way to construct a OPDS request with kiwix/libkiwix#527 but we never update the kiwix-desktop side and so we still construct the request ourselves and we still use the It seems to me that all those features are more a organic evolution and the combination of different features not especially design as a whole. I would propose :
It should not be so complex to implement, just check for the |
@mgautierfr I think your proposal covers current needs but I'm 100% supportive because:
I propose something alternative:
|
Your solution only have one parameters indeed. But the only one paramater will contains all the query and will include
(I suppose a
I'm not sure do understand what is the need here. My solution provide logical operator, so you must think about something specific
Indeed. Do we really need it ?
Difficult to say which future complex requests I suppose.
You will need a bit of code to fully reassemble the multiple filter in a xapian query string.
Indeed. But I really dislike exposing an API from our dependency as our main API. If for some reason we need/want to move out of xapian, we are stuck. The mapping from my solution to the xapian query is pretty easy :
(Of course, we may not use simple string replace and use high level object to do the conversion, we already have a |
I like this proposal because it covers a lot with minimal effort (I think!), acknowledging that it has known limitations. Maybe all current OPDS API users could list their current and expected use cases (and query format). That would help ensure there's no dead spot, and could serve to write unit tests. If all are met with this and it's as easy as it sounds to implement, it could be a good solution for now (my opinion!) |
The problem with this
notag
parameter is that it complexifies the requests and does not solve the fullproblem. For example it is impossible to make a request with ZIM files havingtag1
ORtag2
... and this seems to be a pretty legitimate and useful request.Considering that we plan to use an in-memory Xapian DB to search in description/title, see kiwix/libkiwix#106, I wonder if we should not put as well the tags/categories in it and allow to make search via simple Xapian operators
https://xapian.org/docs/queryparser.html?
The text was updated successfully, but these errors were encountered: