Support portable, pre-defined, list of content

[dnohales]

Windows and Linux desktop apps has support for a library file which specifies the ZIM files the app should open. I believe this should be supported in macOS as well. I'm not sure how the opened ZIM files are stored currently, maybe in a plist file, should we port that to the Kiwix format? I'm also not sure how we could accomplish the "Simple Portable Case" described in the wiki page, where in Windows you can just put the library.xml file along side the .exe with the ZIM files you want to open.

[kelson42]

@dnohales Thank you for your ticket but this is already quite technical. The use case is exactly the same as in https://github.com/kiwix/kiwix-desktop/wiki/Kiwix-desktop-on-an-USB-Drive-(Portable-version) but for macOS?

[rgaudin]

Thank you @kelson42 for pointing that out. Summarizing the need from @dnohales comments and the link:

Ability to distribute in a removable media (USB stick mostly), both the software and a list of ZIM files in a way that the app works like a silo ; listing only those ZIM files ; offering all ZIMs automatically.

[dnohales]

@kelson42 exactly, that's what I need! On the other hand, using that format for the installed instance (the equivalent of having the library.xml file in C:\Users\<your_user_name>\AppData\Roaming for macOS), at least for my specific use case, is optional. But I pointed that out just to be consistent to what Linux and Windows apps do.

[automactic]

This feature request likely will not get my support.

We are moving away from library.xml and towards a set of OPDS APIs, so it is not gonna just be one single file. Additionally, it would be better to have the app refresh the library periodically similar to the iOS app. Thirdly, adding such functionality would require dealing with issues like diffing, old zim file entry in the xml but not exist on the server, etc.

I am planning to adding macOS support in the current iOS app (macOS catalyst). When the time comes, the new Mac app will share the same set of functionality with the current iOS app.

[kelson42]

@automactic We definitly are moving away from the online library.xml but its future in an offline context is unclear. There is no better solution so far to precisely tell an instance of Kiwix what is the local catalog. This feature is legitimate because Kiwix distributor are fully offline AND want to have a clear control of what will be displayed in the local catalog.

I link here the ticket we have currently at Kiwix-Desktop because I believe creating a local library.xml is maybe just to much of hassle and we might be able to provide something easier.

[automactic]

Why not just do it like the iOS app? Refresh the library when the device is connected to the internet. Then cache the catalog in a local database. User can still browse the local catalog when offline.

What do you mean by "fully offline"? Does it mean those devices will never have internet connection? If that's what you mean, what's the point of showing a local catalog, it cannot download the zim files anyway.

[dnohales]

So, the idea of this is to have a full USB portable experience where the user can open the app and automatically show files already included in the USB stick, without the need of an internet connection.

[automactic]

@dnohales What you are saying now is different from what this issue originally seem to be advocating for. What you are saying now is basically the app should be able to open files on USB drives (perhaps with some sort of auto-detect as an improvement).

However, the issue is saying the app should not only display online zim file catalog but also can import an xml file with zim file metadata in it, which would result in a bunch of issue like conflict resolving, identifying source zim file catalog item, identify outdated zim file so user don't have to bother to try to download them, etc

[dnohales]

@automactic well, I mentioned the library.xml mechanism to allow automatically open files from well-known paths (like relative to the executable in an USB key) since that's what Windows does for supporting those cases.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.