Hi Yakov,
savetiddlers overrides the functions mozillaLoadFile() and
mozillaSaveFile() the same as tiddlyfox. With chrome and now with firefox
(since version 68) loading files from 'file:/' is blocked due to security
concerns, this means that when saving the function recreateOriginal() is
used to create the new twc image. There is a problem with this function, in
that it uses what is in the dom for the new image, this will include the
message box div that has been injected by savetiddlers. It is possible that
other browser plugins will inject in the dom as well. It would be better to
remove the message box from the new image. At present savetiddlers will not
work with a twc that already has a message box div - I will work around
this and produce a new release.
cheers
BJ
On Sunday, July 21, 2019 at 10:54:24 PM UTC+2, Yakov wrote:
>
> Hi Pengju,
>
> суббота, 20 июля 2019 г., 18:14:55 UTC+3 пользователь Pengju Yan написал:
>>
>> Continue the title with "Or we need to modify TWC core substantially?"
>>
>> actually, I'm currently working on this and certain changes will be
> present in TW 2.9.3. I'm certain that async *loading* will make it into
> the next release (loadFile will try to load in an async fashion when it
> gets a second argument which should be a callback; and if XMLHttpRequest
> fails it will fallback to sync loading; also the async part will be in a
> separate method which can be overwritten by some event-driven loader or any
> other service).
>
> Once async loading is implemented (note: loading is used by saving;
> actually, I've already implemented async loading, but I have to test it
> before committing), saving will work "faster" ("hanging" will be shorter)
> and also the road to async saving will be clear.. more or less: saving is
> more tricky because of download saving. Still, I think I have an idea how
> to approach the issue correctly.
>
> When async saving is implemented, savers will be able to overwrite it as
> well and the IO functionality will be consistent (although some work on
> documenting
> the approach
> <https://groups.google.com/forum/#!topic/tiddlywikidev/e8hAHYLWUbQ> is
> also required so that the dev ecosystem becomes stable and there's as
> little need to distinguish TWC and TW5 as possible). However, for TWC
> there's one more issue which is only applies to upgrading the core. In my
> tests of upgrading when Timimi is used as a saver, I've figured that the
> script is injected too late when the upgrading already tried to save and
> failed. Though, that was true for the script in dev environment and things
> (like you've noticed) may be different for production extension and I
> should retest this next week with the Timimi released with my patch for TWC
> support.
>
> I also have to notice that saving methods in TWC should be refactored in
> another aspect: they wrongly mix file manipulation and various reporting
> stuff which makes those difficult to tweak for certain purposes; but that's
> not that important for now.
>
> I used savetiddlers <https://github.com/buggyj/savetiddlers> (only
>> version 0.6 worked on my FireFox with macOS while 0.8 simply didn't) to
>> save my TWC until FireFox was automatically updated to 68.0.1 last week.
>>
>> I learned all the code of savetiddlers and the saving mechanism of TWC
>> while I was trying to fix some problems in savetiddlers. Although I'm not
>> 100% sure, I'm suspicious about the asynchronous philosophy (as Yakov
>> mentioned several times), at least for the current implementation of TWC
>> core.
>>
>> To my understanding, saveMain() in TWC will set the dirty flag to false
>> after saveFile() returns. Consider you are working a big TWC file, and
>> saving take several seconds to accomplish. Between subsequent 2 savings,
>> something will happen this way:
>>
>> 1. You finish editing a tiddler A and click the done button. A save
>> message will send to a saver.
>>
>> 2. Because the saving operation is asynchronous, saveFile() immediately
>> returns and then the dirty flag is set to false.
>>
>> 3. The saver is downloading the new TWC file with the update tiddler A.
>>
>> 4. Before the new TWC file downloading finishes, you edit another tiddler
>> B and finish editing it and click the done button. The TWC core will load
>> the original TWC file from the local file system *WITHOUT* the updated
>> tiddler A, and send another saving message to the saver. Because in step 2
>> the dirty flag is set to false, this time the updated content contains only
>> updated tiddler B and the *ORIGINAL* tidder A (tiddler A is thought to
>> be already up-to-date).
>>
>> Is it how SaveTiddlers work? Because there's no such problem for TWC
> usual saving which is not tiddler-wise. Instead, it loads "original" (TW
> file), grabs the TW core and ignores the content completely and puts the
> current content into that core and than saves the file.
>
> I've implemented tiddler-wise saving (I also call it "granulated") in
> MainTiddlyServer <https://yakovl.github.io/MainTiddlyServer/>, but
> there's no such problem too because granulated saving doesn't load original
> at all: instead, it sends "changes" to the server and it updates TW (yeah,
> this requires the server to understand TW structure). MTS also supports
> non-granulated saving which is used for TWs below 2.8.1.
>
> 5. The saver makes a new download operation where the TWC file to be saved
>> contains only the original content with the updated tiddler B.
>>
>> 6. A few seconds later, the first downloading finishes, now the local TWC
>> file contains original content and updated tiddler A.
>>
>> 7. Another few seconds later, the second downloading finishes, now the
>> local TWC file contains original content and updated tiddler B.
>>
>> 8. Note that ultimately you lose your work on tiddler A.
>>
>> To be honest, I haven't done any test to check whether the situation
>> above will happen. But anyway, I think asynchronous saving needs more
>> thorough thinking.
>>
>> To enable asynchronous loading and saving, I think we need to modify TWC
>> core so that only if a "save-successful" message is received then the dirty
>> flag could be set to false.
>>
>> See above
>
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywikidev/08fbdfde-6702-4603-93b9-afa46b0af11a%40googlegroups.com.
