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/c6fdc1b8-0e76-41f6-b9d4-db98e843d3d6%40googlegroups.com.
