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.

[kelson42]

@rgaudin @dnohales @BPerlakiH Please correct me if I'm wrong, but the standard way of making macOS apps portable is the DMG format and this format requires to be installed AFAIK. Or do we have an other reasonable way to make apps portable?

[rgaudin]

• DMG is just a container
• Most Apps (including Kiwix) are usually distributed as self-contained .app file (actually it's a folder)
• .app folders are usually distributed inside a DMG (as we do) or inside a ZIP. Installers are rare and used when app needs to add stuff to the system (and does not want to do it in an initial launch for instance)
• Other method is through App Store which adds constraints.

That's about distributing the App. In that sense, ours is already portable.

But a portable App is mostly about where it stores content. In that, Kiwix is not portable. It uses what the system requires (~/Library/Containers/Kiwix now).

We could add a mode where we read and write our data elsewhere I believe. That would trigger a system popup asking the user whether he allows access to that location. I'm not sure we can point it to inside the .app itself but we could distribute a writable-DMG (so not ISO9660) with the data next to the app. I think that would be quite convenient.

[BPerlakiH]

Currently the locally opened files are stored in a database, which is going to be part of the app container, this is rather small in size, so we can still have the ZIM files on an external USB as described above. Additionally to that, once the app is installed (eg. from the USB), selecting and opening all the ZIM files from the USB folder will automatically parse the metadata from those files and insert into the DB, so it's a 1 time operation. After that opening the app, it should find all those ZIM files.

[kelson42]

@rgaudin @BPerlakiH Thank you for your feedbacks. This is clearer now for me. But we need first to use library.xml in place of the custom solution for the local library.