I actually implemented something similar in an experimental branch to the launcher idea a while back but abandoned it because it felt very clunky to me slaymaker1907/TW5-browser-nativesaver at sync-adaptor (github.com) <https://github.com/slaymaker1907/TW5-browser-nativesaver/tree/sync-adaptor> .
The biggest problem was that sync adaptors don't work as nicely as regular savers with falling back to another saver in case of errors. If people were interested in that approach, it would probably be better done as a separate plugin and just duplicate code since savers work very differently compared to sync modules. It's also a lot more work since there is much less documentation on sync adaptors compared to vanilla saver modules. One thing I still like about the sync adaptor/folder wiki idea is that versioning can be done much more cheaply (at the cost of recovery complexity if you want to go back to an old version). Instead of just saving the whole wiki each time, the plugin could just save the old version of the changed tiddlers. If the API supported it, I'd love to just save the old versions in a compressed file so it takes up less space. However, that isn't really practical since JSZip is a huge dependency for one plugin and because the file system API can't do changes in place. You have to completely write the whole file each time. Thinking about that issue though, I could possibly implement gzip compression for the individual versioned files. Plain gzip at level 5 gives a compression ratio of ~17% for the example wiki (so compressed it is 17% the size of the original) which is quite a bit. I don't want to do some sort of diff or patch algorithm since I don't know if I trust myself enough to implement such a thing correctly plus you can't just use 7zip in that case to recover the data. isomorphic-git · A pure JavaScript implementation of git for node and browsers! <https://isomorphic-git.org/en/> might also work so it's just a git repo in that case. In terms of stressing if you picked the right file, assuming you used the modal button, you don't need to stress out too much since the consistency check should catch that. On Saturday, February 19, 2022 at 5:45:06 AM UTC-8 [email protected] wrote: > On Fri, Feb 18, 2022 at 8:16 PM Frédéric Demers <[email protected]> > wrote: > >> As inspiration, this seems to be a decent implementation of native file >> storage API: https://bangle.io >> > > This does look pretty good. Another example is https://app.diagrams.net/. > > These two apps have a webpage at a well-known url which holds the > javascript functionality. The data files are loaded in separately. Compare > this to tiddlywiki in which the functionality and the data is combined > together into a single file. > > I think to implement the same workflow in tiddlywiki, you'd have to have a > "launcher" instance of tiddlywiki which would read a tiddlywiki instance > from disk as the "data file". > > I seem to recall https://tiddlywiki.fission.app/ implements such a > launcher, but currently that page has an endlessly spinning "Authorizing > with fission" message and the console has an "Uncaught (in promise) Error: > Improperly formatted header value: skeleton" in webnative.js, so I couldn't > confirm my memory. > > I think the workflow implemented by the above two apps is "safer" than > what I saw in the TW chromium native file saver. With the TW native saver > the workflow looks like this: > > 1. Load my native saver enabled TW using some url (possibly a file:// > url) > 2. Click the Save button in HTML Native File System Saver modal > 3. From the file dialog select the same file I'm already editing > 4. Dialog box "a file with this name already exists, do you want to > replace it?" > 5. Start sweating a little bit...if I've chosen the wrong file here, I > might be overwriting something important > 6. Sweat a little bit more especially if I've loaded it from a web url > where it isn't as easy to tell that I've selected the matching file or not > 7. Cross my fingers, click the "replace" button and hope for the best > > The bangle and diagrams.net applications don't have the same room for > user error since you are prompted for what file to read and then it > automatically saves back to that same file. I find that workflow to be less > nerve-wracking. > > Maybe with tiddlywiki's unique structure there is an even better workflow > to be had, I don't know. And maybe the TW nativesaver can already be used > with a better workflow and I just missed it. > > >> On Fri, 18 Feb 2022 at 20:13, TW Tones <[email protected]> wrote: >> >>> Folks, >>> >>> I believe this is already available on tiddlywiki.com at >>> https://tiddlywiki.com/#Saving%20on%20Browser%20with%20File%20System%20Access%20API >>> >>> It is not yet comprehensively documented and it is hard for me to >>> determine what level of functionality and customisation is available to us. >>> As a solution only on Chromium browsers it is not yet global in >>> application, so understanding its value is even harder to determine. >>> >>> I also ask myself "We require a click event to start the save dialogue" >>> if this could not be placed in a save button "lookalike" or another way to >>> make it user friendly. Ie just in time, not startup, Although in this >>> thread others suggest they do not need it. >>> >>> Can someone write a user designer perspective and/or comparison with >>> existing methods? >>> >>> My concerns; >>> >>> - How to design online tiddlywikis with a non-intrusive saving >>> mechanism users can understand. >>> - Dealing with the contention possible with two parties editing the >>> same site. >>> >>> I would appreciate it is someone can spell this out a little more for us >>> who need it, and can't easily understand this from the jargon and reading >>> between the lines in this discussion. >>> >>> Thanks >>> Tones >>> On Wednesday, 9 February 2022 at 11:10:40 UTC+11 PMario wrote: >>> >>>> Hi, >>>> I do like that option. >>>> -mario >>>> >>>> On Wednesday, February 9, 2022 at 12:11:06 AM UTC+1 [email protected] >>>> wrote: >>>> >>>>> It does work, though I think it is disruptive asking as soon as >>>>> something is done which triggers autosave. However, I have put in an >>>>> option >>>>> with version 0.7.1 to disable the modal for those who don't like it. >>>>> >>>>> On Sunday, February 6, 2022 at 1:46:16 AM UTC-8 PMario wrote: >>>>> >>>>>> On Sunday, February 6, 2022 at 12:54:25 AM UTC+1 [email protected] >>>>>> wrote: >>>>>> ... >>>>>> >>>>>>> Now with the indexdb entry re-populated, the sequence looks like >>>>>>> this: >>>>>>> >>>>>>> 1. Reload the TW page >>>>>>> 2. Click the + button to create a new tiddler >>>>>>> 3. Click the checkmark to save the tiddler >>>>>>> 4. A dialog box asks me if I want to let the site edit the file. >>>>>>> I click the "edit file" button >>>>>>> 5. The file saves >>>>>>> >>>>>>> So it is working for me even without the settings modal. Do you see >>>>>>> this same behavior? >>>>>>> >>>>>> >>>>>> I also think the modal isn't needed. The API requires user >>>>>> interaction. ... But I think the described behaviour is good. The >>>>>> permission is requested, when the first save happens. Since this save is >>>>>> a >>>>>> user interaction it should be good enough. >>>>>> >>>>>> -mario >>>>>> >>>>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "TiddlyWiki" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/tiddlywiki/ihoCXMIkz9I/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/tiddlywiki/6ee85fa3-f495-4a11-874d-01aa02db7a52n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/tiddlywiki/6ee85fa3-f495-4a11-874d-01aa02db7a52n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> > You received this message because you are subscribed to the Google Groups >> "TiddlyWiki" group. >> > To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/tiddlywiki/CAAY2DnOq8LXuyC_4YJR6Q7KTU7%2Bek%3Ds_ZhGbYG_qa4PMEpir1A%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/tiddlywiki/CAAY2DnOq8LXuyC_4YJR6Q7KTU7%2Bek%3Ds_ZhGbYG_qa4PMEpir1A%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/31e7f46d-70ec-4e77-9819-865e5eff0b09n%40googlegroups.com.
