When may we stop supporting the old namespace scheme?

[veloman-yunkan]

Currently zim::Archive::getEntryByPath() allows to access an entry at ZIM-path PATH in a ZIM file complying to format v6.1+ (having the "new" namespace scheme) using any of the following strings:

• PATH
• L/PATH where L is any single character different from /
• /L/PATH where L is any single character different from /

Dubious accesses via the contrived paths L/PATH and/or /L/PATH are meant to account for references possibly remaining from the days of old namespace scheme and they will resolve to the entry at PATH unless the ZIM file also contains an entry at the requested path (i.e. L/PATH and/or /L/PATH) in which case that latter entry is returned.

Relevant code:

https://github.com/openzim/libzim/blob/9.8.1/src/archive.cpp#L294-L301

https://github.com/openzim/libzim/blob/9.8.1/src/tools.cpp#L96-L107

https://github.com/openzim/libzim/blob/9.8.1/test/parseLongPath.cpp#L45-L59

I think that we should get rid of that legacy sooner or later, since such a behaviour is prone to errors like below:

Scenario 1

Both a/b/c.htm and b/c.htm must be added to the ZIM file but for some reason a/b/c.htm is omitted. zimcheck will fail to mark any links resolving to a/b/c.htm as dangling - accesses through those links will return the content of b/c.htm instead.

Scenario 2

ZIM file creation flows with remnants of logic relying on the old namespace scheme may produce a ZIM file with articles A1 at xyz and A2 at A/xyz and keep referring to them, respectively, as A/xyz and A/A/xyz (i.e including the article namespace A). But (assuming that no other ZIM entries interfere) both of those paths will resolve to the second article (A2 at A/xyz).

[kelson42]

I think this is a good issue to tackle once we will work on version 10.