Supporting Catalog Updates
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 7
- Forks
- 1
- Avg merge
- 15h 20m
- Merged PRs (30d)
- 18
Description
As discussed the other day with @benoit74, it makes little sense in the library.kiwix.org infra to always request and receive the whole catalog from the CMS, then parse it and compare with a local copy to find out what changed and clear the cache for those books.
@kelson42 suggested we could send a datetime as input and the CMS would only return books published (added, modified) since that date.
While it would indeed work for new or updated ZIMs, it would not inform about any removal (unpublish) from the Catalog which defeats the core purpose of the CMS.
Supporting deletions would imply using a custom format instead of the plain old Library XML.
I am opening this issue to record the discussion but I think that we should proceed as planned for the moment.
We can later improve with a more sophisticated solution. I think the pub/sub pattern would be a good candidate.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names the CMS catalog flow, Library XML, and a possible pub/sub approach, but no files, tests, or entry points. Start by reviewing the catalog update discussion and current CMS response behavior. Done is not defined; the issue would need an agreed deletion-aware update format and acceptance criteria first.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100