Hi Yakov > Second question is: why all the savers call the callback with null as the > first (and only) argument? I guess, it's a placeholder for some specific > design, could somebody clarify it?
Invoking the callback with null indicates that there was no error. An error is indicated by passing a string. You can see the callback that is used when the savers are invoked here: https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/saver-handler.js#L163-L177 <https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/saver-handler.js#L163-L177> > Finally, and that's my main current concern, I'd like to discuss the events > system. The thing is, as far as I can see, "tiddlyfox" saver only relies on > the tiddlyfox-have-saved-file event fired on successful saving, it doesn't > listen to any ~tiddlyfox-have-failed-to-save-file event. That’s correct. The TiddlyFox design assumes that the save succeeded if TiddlyFox accepts it. (The reason is that originally TiddlyFox was implemented for TWC where the save functions are synchronous, but we were actually triggering an asynchronous operation. Thus there was nowhere to deliver the asynchronous error return). > And hence Timimi doesn't implement firing such events. Which is not nice in > some cases (say, you have a TW on a removable USB storage device, you remove > it, then press save, and don't get any notification about saving actually > failed) and for some applications (well, that's needed at least in TWC > upgrading engine which displays the stage/status of the procedure). So I'd > like to propose introducing such an event. But since Timimi is designed for > TW5 in the first place, I'd like to discuss the design of the event with you > so that Rizwan have a reference and can participate the discussion too. > > Now, tiddlyfox-have-failed-to-save-file is definitely not a nice name, > because TiddlyFox is both outdated and doesn't fire such an event. So it > should be something more abstract, I think. Like > tiddlywiki-saver-have-failed-to-save-file or something shorter like > tiddlywiki-saver-fail. Ideally, such an event should hold some values that > help identify the cause of a fail (folder doesn't exist, permission denied, > .., unknown), presumably in a form of some codes (unknown = 0, folder doesn't > exist = 1, ...) so that localization is possible. A second thought is: if > such new event is introduced, perhaps new events should be used for > saving-request and saving-succeeded too (both old and new events should be > fired for backward compability): I'd propose tiddlyfox-have-saved-file → > tiddlywiki-saver-success and tiddlyfox-save-file → tiddlywiki-saver-request. > So that we have: > > init saving: tiddlywiki-saver-request (+ tiddlyfox-save-file for backward > compatibility) > saving succeeded: tiddlywiki-saver-success (+ tiddlyfox-have-saved-file for > backward compatibility) > saving failed: tiddlywiki-saver-fail > > Perhaps an even better choise would be to give names for arbitrary IO > operations (saving, loading, saving binaries etc) which could be: > > init saving: tiddlywiki-backend-save-request (+ tiddlyfox-save-file for > backward compatibility) > saving succeeded: tiddlywiki-backend-save-success (+ > tiddlyfox-have-saved-file for backward compatibility) > saving failed: tiddlywiki-backend-save-fail > and can further be extended to things like > tiddlywiki-backend-load-request, -success, -fail > etc > > What do you think? We could perhaps stick with “tiddlyfox” in the names, with the idea that we’re re-assigning the name to refer to the protocol rather than the original Firefox extension. In the docs we’d talk about the “TiddlyFox protocol”. Perhaps the next step is to formally document the current V1 TiddlyFox protocol at tiddlywiki.com/dev, alongside the proposal for the V2 protocol. Most important is to retain as much backwards compatibiltiy as possible. A v1 tiddlyfox saver in TW5.1.x should work with a V2 tiddlyfox host, and vice versa. I’m happy to update TiddlyDesktop to the new protocol. Best wishes jeremy > PS1 I think the scope of docs which I proposed in this thread is actually > "TiddlyWiki interoperability and data formats". > > PS2 Besides multiline fields, there's another issue about .tid format, namely > convention regarding filenames (say, tiddler name contains * which is not > allowed in filenames – what should be the .tid filename? Obviously, the > convention should describe a reversible convertion (without ambiguities). The filename of .tid files is ignored; the system uses the title field within the file as the tiddler title > > среда, 10 апреля 2019 г., 12:37:38 UTC+3 пользователь PMario написал: > On Sunday, March 24, 2019 at 3:58:40 PM UTC+1, Yakov wrote: > ... > in the latest release of TiddlyWiki Classic I've fixed the upgrading engine > and now it's time to deal with saving more consistently. That's where I'd > like not only to ask about some dev aspects but also discuss some conventions > and create docs for consistent support of saving both TWC and TW5. > > Some basic info about savers can be found here: > https://tiddlywiki.com/dev/#Saver <https://tiddlywiki.com/dev/#Saver> > > If you have a closer look at the implementations > <https://github.com/Jermolene/TiddlyWiki5/tree/master/core/modules/savers> > > - tiddlyfox.js ... outdated, but the mechanism is the same. > - beaker.js ... new saver using the dat-project > - put.js ... WebDav PUT saver. > > IMO this info should be enough to create your own simple saver. ... I think > the upload.js used a php server side. > > If a "save action" is triggered, the core uses the saver.canSave() info to > check if the saver can be used at all. saver.info() returns the saver > capabilities and the priority. > > If several savers are able to provide the needed save action, the saver with > the highest priority wins. ... ATM "There can be only one > <https://www.youtube.com/results?search_query=there+can+be+only+one>!" > > have fun! > mario > > -- > You received this message because you are subscribed to the Google Groups > "TiddlyWikiDev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/tiddlywikidev > <https://groups.google.com/group/tiddlywikidev>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywikidev/4592137f-a8e6-442f-82fe-f96ab88599e9%40googlegroups.com > > <https://groups.google.com/d/msgid/tiddlywikidev/4592137f-a8e6-442f-82fe-f96ab88599e9%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/tiddlywikidev. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/79339154-2CB6-4249-9801-81167F62AB33%40gmail.com. For more options, visit https://groups.google.com/d/optout.
