CMS - Expose "private" collections and ZIMs in a "kiwix-serve" and for download
- Dominant language
- Python
- Stars
- 15
- Forks
- 5
- PR merge metrics
- No merged PRs in 30d
Description
With the deployment of the CMS, we now have:
- https://dev.library.kiwix.org which exposes **all** ZIMs in CMS staging area
- https://library.kiwix.org which exposes Kiwix CMS collection (or will in coming days more exactly)
We do have other collections which are not exposed in a library: branded_apps, bsf, bard, endless. These were exposed in https://dev.library.kiwix.org but this is not straightforward anymore, and I'm not convinced it is the right design anymore.
We also do have https://clients.library.kiwix.org which does expose few individual private ZIMs or private collections in a pretty adhoc manner. This involves editing a YAML file which is pretty error-prone. Both at edit time but also in term of maintenance (ZIMs gets deleted / moved and configuration becomes broken).
I feel like it is time to discuss the need again around these private collections and ZIMs and maybe (or not) identify a common and convenient solution now that we have the CMS in place.
Depending on target design we might need to modify CMS or not, hence the question in kiwix/operation at first.
Contributor guide
Research direction
Start by reviewing how dev.library.kiwix.org, library.kiwix.org, and clients.library.kiwix.org currently expose collections and ZIMs, including the YAML configuration mentioned for private content. Compare the existing CMS and kiwix-serve arrangements, then document an agreed common design whose configuration remains valid when ZIMs are deleted or moved.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes, yaml
- Domain
- devops, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100