This is a very old topic but I don't find any traces of discussions anywhere, so let's create a new one.
Editing a ZIM (like modifying its content) is not currently possible. Current solution consists in recreating it with a "zimwriterfs" approach (copy everything from "bad" ZIM to "new" ZIM with patching of required changes.
This is not really convenient because:
- we do not have good tooling to describe the changes we wanna make in the ZIM (maybe we could simply work on that), causing manual code to be needed
- it consumes twice the ZIM size in disk space
- it is not exactly fast on big ZIMs
In my duties, I see two types of moments where I would really like to be able to edit a ZIM:
- when Zimfarm has created a ZIM (sometimes a long time ago) and we realize a metadata is wrong
- when I'm debugging a ZIM issue and wanna tweak an HTML/CSS/JS file to confirm the issue / fix needed
Editing a ZIM in-place would be very convenient for these two use-cases.
I imagine it would probably lead to sub-optimal ZIM size (because we have insufficient space for new dirent content and we need to move it to a new cluster at the end of the file, leaving a "hole" where previous content was) but this is a negligible aspect IMHO. We could even imagine to optionally "defragment" in a later stage if ZIM size is significantly impacted (I don't think it will, for prod ZIM we speak only about metadata for now, and larger modifications are only for dev purposes where we don't care about fragmentation).
Does this effort makes sense to be implemented / planned?
This is a very old topic but I don't find any traces of discussions anywhere, so let's create a new one.
Editing a ZIM (like modifying its content) is not currently possible. Current solution consists in recreating it with a "zimwriterfs" approach (copy everything from "bad" ZIM to "new" ZIM with patching of required changes.
This is not really convenient because:
In my duties, I see two types of moments where I would really like to be able to edit a ZIM:
Editing a ZIM in-place would be very convenient for these two use-cases.
I imagine it would probably lead to sub-optimal ZIM size (because we have insufficient space for new dirent content and we need to move it to a new cluster at the end of the file, leaving a "hole" where previous content was) but this is a negligible aspect IMHO. We could even imagine to optionally "defragment" in a later stage if ZIM size is significantly impacted (I don't think it will, for prod ZIM we speak only about metadata for now, and larger modifications are only for dev purposes where we don't care about fragmentation).
Does this effort makes sense to be implemented / planned?