[IDEA] Implement file system access api

[a-gerescher]

Is your feature request related to a problem? Please describe.

Default save without extension does not work anymore.

Describe the solution you'd like

For chromium based browsers implement file system access api.

Describe alternatives you've considered

None.

Additional context

W3C Draft Chrome 86 Stable Changelog Example and explanation

[pmario]

I did try the demo-text-editor with MS Edge and it seems to work. .. Good catch!

[Jermolene]

Hi @a-gerescher @pmario I've also been watching the File System Access API with great interest. The problem right now is that browser support is poor:

So, my first thought would be that we should explore using the API via a plugin for the moment. But I do see that it would be attractive to add to the core just for Chrome if the code were brief enough. Perhaps a good first step would be to explore updating this simplified test rig I made for the default download saver before I began work on TW5:

https://github.com/Jermolene/FileSavingDemo

[a-gerescher]

I will look into it during my free time at the weekend. Progressive enhancement via feature detection should be possible.

[slaymaker1907]

I implemented a very small saver that could probably be adapted into something suitable for core. The main concern I have is that I'm not aware of a way to unload a broken saver which would definitely be required for something this unstable.

https://gist.github.com/slaymaker1907/7a04a6188179bfe113b122b1f51e22b5

This also highlights some weaknesses with the canSave() model. We can't really prove that the file system saver works because:

1. canSave() is synchronous and the file system APIs all return promises
2. window.showSaveFilePicker only works when initiated by a user action

The first problem is fixable, but the second basically requires some mechanism to indicate to TW that the saver is broken and to try another one. Ideally it should permanently disable the saver until explicitly reenabled.

EDIT: I just realized that it does actually work in case problems are encountered since it returns false for subsequent saves when a given save fails. In this case, something similar to the above saver could probably be added to TW after cleaning up the code.

[kookma]

Hi @slaymaker1907 I may recommend to first consider this as a plugin to see how it works!

[Jermolene]

Thanks @slaymaker1907 I've copied my reply from your mailing list post here:

I wrote a small module for saving using the Chromium file system API (which is in the process of being standardized).

Example TiddlyWiki 5 Saver Using HTML 5 File System Access API (github.com)

Great stuff, I’ve been following the File System API with interest, and would be keen to get a saver in the core once the spec settles down.

Here’s a link for those unfamiliar:

https://web.dev/file-system-access/

I don’t know if any other browsers are planning to implement the API. It seems like an obvious requirement for ChromeOS, but perhaps other browsers will have less incentive to implement.

The first time a save action is triggered, it prompts for a save location but future saves should go to the same location.

It's a bit dangerous because if saving fails, there is no way AFAIK to disable the saver after it loads. I would be interested to know if anyone knows a way to disable a saver after it has already loaded.

I think you’re already following the correct approach: for the save() method to synchronously return false if the save cannot proceed so that the next saver in the cascade gets a chance.

Another thought with respect to the File System API is that it may be possible to write a syncadaptor module so that we can support TiddlyWiki folders containing individual .tid files in the browser.

[pmario]

Another thought with respect to the File System API is that it may be possible to write a syncadaptor module so that we can support TiddlyWiki folders containing individual .tid files in the browser.

IMO this "sync adaptor" should be like a "middleware". I know, that FireFox is panning to have a "File System"-like API which can be accessed from browser AddOns. ...

So the syncer should be able to communicate with the file-API in the browser or a file-API in an addON ... That would be great!

[Jermolene]

IMO this "sync adaptor" should be like a "middleware". I know, that FireFox is panning to have a "File System"-like API which can be accessed from browser AddOns. ...

So the syncer should be able to communicate with the file-API in the browser or a file-API in an addON ... That would be great!

That's the architecture that we already have: the syncer module encapsulates the synchronisation logic and the syncadaptor is a simple abstraction of the CRUD primitives. Right now we have the same syncer working with the tiddlywebadaptor in the browser and with the filesystemadaptor on the server.