Investigate adding Filesystem access with the File and Directory Entries API

[Jaifroid]

This API is relatively new, not yet standardized, but seems to have good asynchronous support for read-only, which is what we want. See:

https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API

[Jaifroid]

There is a good introductory document on this API here:

https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API/Introduction

It includes amongst the use cases:

• Offline video viewer
  The app can download large files (>1GB) for later viewing.
  The app can access partially downloaded files (so that you can watch the first chapter of your DVD, even if the app is still downloading the rest of the content or if the app didn't complete the download because you had to run to catch a train).

The mention of large files > 1GB sounds promising. This is also stated:

The app can restart [file access] after an interruption, such as the browser being closed or crashing, connectivity getting interrupted, or the computer getting shut down.

(It actually says "uploads" where I've put "file access", but this is in the context of a file-uploader example.)

[Jaifroid]

So, having looked into this, it seems there is no way to store a file handle between sessions using this API, even for read-only. EDIT: If the file is stored in the virtual file system, then it can be accessed across sessions. However, given the large size of our files and the fact that the browser manages the storage, probably on the System drive, this seems useful only for a small ZIM file. I think this is rather similar to what Firefox is doing on Android: when you pick a file, it copies it to its own virtual filesystem, but with our files, this takes several seconds and is not very convenient.

A better upcoming API for our purposes might be the Native File System API which is currently Chrome only and behind an experimental flag. There is an explanation here: https://web.dev/native-file-system/ . This includes the following statement:

In the next few versions of Chrome, installed Progressive Web Apps (only) will also be able to save the handle to IndexedDB and persist access to handles across page reloads. In this case, an icon will be shown in the omnibox as long as the app has write access to local files.

So this technology would be used alongside #388. WC3 has a draft spec, but it is not on standards track: https://wicg.github.io/native-file-system/ .

This could be quite promising if Mozilla gets on board.

[mossroy]

The main issue with the "File and Directory Entries API" is that, as far as I understand, you can not read files in the actual filesystem of the device, but only in the sandboxed filesystem. And this sandboxed filesystem can not be accessed outside the app.
I suppose it implies that the ZIM file has to be downloaded by the app itself. i.e the ZIM file can not be side-loaded from an offline source.

The "Native File System API" looks more promising, but it's currently not implemented anywhere (except on Chrome behind a flag) : https://caniuse.com/#feat=native-filesystem-api

[Jaifroid]

Yes, I came to the conclusion that the File and Directory Entries API, while a lot better supported recently than the old Chrome-only Filesystem API (basically because the other browsers were forced to implement parts of it or see their browsers fail on popular sites) is only useful for downloading a smallish (e.g. up to size of WikiMed) ZIM and storing it in the sandboxed File System. If this could be done on user request, it would be an advance: you then have a two-part "Packaged App" - download the app (or install as PWA) and the app then downloads the ZIM file it needs to complete its "installation". It could also incorporate a check for an updated ZIM on user request (or use notifications). However, a lot of other development would be needed to get to that...

[Jaifroid]

This issue can be closed because the Native File System API is superior and working in Kiwix JS Windows.