The time window would work something like this. Let's say you have the wiki open in one tab and you do some editing and the changes get saved. Can you open it in another tab or window or on another computer, and make some changes there. Then you come back to the first computer or tab and without thinking you make some changes and they automatically get saved. If neither the backup feature nor Etag is enabled, your changes are irretrievable lost, unless your backup system already grabbed them as soon as they were written.
The backup feature of TiddlyServer lets you retrieve that old version, and the e-tag prevents it from being overwritten in the first place. Now if I would put a time window in place of, say, 10 seconds, it would be able to save only if the file on disk is nor more than 10 seconds newer than the version loaded in the browser. If it was modified more than 10 seconds later than the version in the browser it would not be able to save. This would be a setting in settings.json so the user could adjust it according to the need. Interesting thought, I will consider it. Arlen On Oct 27, 2017 10:41, "coda coder" <[email protected]> wrote: > Let me say this another way... > > A PUT request is an undeniable request made by the client, Honor it. > Honor it and let the issuer own the consequences. > > > On Friday, October 27, 2017 at 9:35:43 AM UTC-5, coda coder wrote: >> >> >> >> On Friday, October 27, 2017 at 7:38:48 AM UTC-5, Arlen Beiler wrote: >>> >>> The backup feature could probably be better described as a complete >>> version history. I can disable e-tags if someone is using backups and they >>> won't lose anything. >>> >> >> I don't know the detail, unfortunately, but if disabling e-tags is in >> essence what I was asking you for, that's the option I (personally) would >> prefer. >> >> >>> >>> The other option is to add a setting that would allow you to set a time >>> window within which an e-tag is valid. So if most of your e-tags are off by >>> one second, you can set a window of five seconds and a request with an Etag >>> that is within 5 seconds of the modified time will get saved. >>> >> >> There's a difference between backing up a TW when it is first opened from >> disk and backing up on a save-by-save basis. I'm assuming we're talking >> about the former, not the latter. The former is what I assume you mean by >> "version history". >> >> I already have that in place and don't see any need to change it, though >> I maybe would if I felt the need -- can't imagine what that need might be >> though. >> >> As regards the time window... any code that takes a "best guess" at the >> appropriate period of time is likely to suffer from distrust. Also, I have >> some wikis that are open for weeks and many others that are transient >> throughout a single day. Some are modified a lot, others rarely. I just >> don't know what time period I'd pick. And then I'd always wonder if my >> next save was going to suffer a 412 because I'd chosen a poor "best guess" >> period. Hence, distrust. >> >> Really, honestly, I'd prefer no time checking at all. Then, as I said >> above, TS would become usable (and, trustworthy). >> >> >>> >>> On Oct 26, 2017 2:25 PM, "@TiddlyTweeter" <[email protected]> wrote: >>> >>> The whole question of backup in TW is something that has interested me >>> from when I started. >>> >>> I have formed an OPINION on it. >>> >>> (1) its nice when it can be made to work seamlessly from within TW. A >>> plus--but not a necessity. I'd rather programmers didn't struggle over it >>> though. I'd rather they paid central attention to keeping TW up and >>> running--something only they can do. >>> >>> (2) backup is very appropriately handled by Backup Programs. The good >>> ones give multiple options that far exceed anything TW can do because they >>> are dedicated to that one task. >>> >>> Best wishes >>> Josiah >>> >>> -- >>> 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 post to this group, send email to [email protected]. >>> Visit this group at https://groups.google.com/group/tiddlywiki. >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/tiddlywiki/7127d415-6d48-484f-86bb-2386c25aa2b7%40googlegroups.com >>> <https://groups.google.com/d/msgid/tiddlywiki/7127d415-6d48-484f-86bb-2386c25aa2b7%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- > 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 post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/tiddlywiki. > To view this discussion on the web visit https://groups.google.com/d/ms > gid/tiddlywiki/bdc6284f-488d-4456-8343-34e72f6e7749%40googlegroups.com > <https://groups.google.com/d/msgid/tiddlywiki/bdc6284f-488d-4456-8343-34e72f6e7749%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAJ1vdSQXnE4Am_8R5uBd8%2BUG%3DofxPA8SRqC0zb2Phx5TmKMCtQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
