Optionaly include path attribute in catalog

[rgaudin]

kiwix-serve in --catalogOnly mode needs every book to have a path attribute as that's what it uses to build path prefixes.
FYI it is not using ZIM metadata (Name) for that because of conflicts that could occur.

In the non-CMS world, we'd generate a path attribute based on url attribute when the XML is to be used in --catalogOnly.

Now, I had to replicate that hack but it seems to me that this is something that the CMS should do, upon request.

Can we imagine passing a param (?addPath to /collections/xxx/catalog.xml) and receive the catalog with path` attr on books? Value would be the folder and the filename.

[rgaudin]

Actually, we have three use cases:

• [staging]: we use actual files so we need path to match our physical ones. For some reason, /staging/catalog.xml is returning the catalog with path="/data/xxx
• [catalog]: we run on --catalogOnly. We need path attribute but don't care about the prefix.
• [browse]: we use actual files so we need path to match our physical ones.

I think the best would be that this param passes the wanted prefix.

[kelson42]

I just land on this issue, but to me it sounds very strange that the CMS shares paths. Just a first impression.

I don't understand why paths are necessary for anything else than the "browse" feature... and in that case I see no reason why this should not be handled locally.

I put a question tag here. All of this is a bit of a detail, but maybe it leads to a more interesting discussion...

[benoit74]

Can we imagine passing a param (?addPath to /collections/xxx/catalog.xml) and receive the catalog with path` attr on books? Value would be the folder and the filename.

Yes definitely, LGTM.

For now CMS is replicating the "logic" used so far in XML file:

• no path attribute on collections
• a path attribute on staging with a prefix customizable through STAGING_LIBRARY_XML_BASE_PATH

This was indeed a bit awkward since this is very related to how the XML file "user" setup its filesystem mount points (contrary to warehouse paths which are linked to how the CMS setup its own filesystem - on the shuttle).

We can definitely add an optional path_prefix (snake case for consistency if I'm right, and more accurate name if it suits you) query parameter. If path_prefix query parameter is not passed, then we do not set the path attribute in generated XML. If path_prefix query parameter is passed (even empty) then we set the path attribute in generated XML + we use the path_prefix value as path prefix.

@rgaudin would that match your need? How should we handle the transition? You start passing the query parameter now and disable the hack when path is already set in the XML?

[rgaudin]

@rgaudin would that match your need?

Absoluetely

How should we handle the transition? You start passing the query parameter now and disable the hack when path is already set in the XML?

When you have the feature ready, don't deploy but inform me, I'll pause the refresh (use extra long interval) then you can deploy and I'll adapt code and deploy the new version soon after.

[rgaudin]

I just land on this issue, but to me it sounds very strange that the CMS shares paths. Just a first impression.

I don't understand why paths are necessary for anything else than the "browse" feature... and in that case I see no reason why this should not be handled locally.

I put a question tag here. All of this is a bit of a detail, but maybe it leads to a more interesting discussion...

@kelson42 can you re-read my messages? I think it's all there. I would only be paraphrasing myself. Or I can explain live.

[benoit74]

@elfkuzco please proceed with implementation. Discussion with @kelson42 might bring new perspectives for the future but I'm quite sure it won't change the immediate need (and it is not like this is a very big feature we would have lost our time working on).