Hi PMario,

Thanks for the detailed explanation.
I agree that the general case is quite complicated (collision handling as 
you say for instance).

But I was talking about a more simple use case : serving and saving local 
files (on the local filesystem or on dropbox or onedrive as you have local 
copies of the files). There should (?) be no access conflict on the files 
(of course it may happen, but you should master your own files ...).
The backup folder could bee created before using the saver or the webdav 
server could maybe do it (after all it's on your filesystem).

So I'm pretty much in the case you refer as "local backups".

Maybe something like a "putlocal.js" file with backup ability could be 
created from the put.js. That was more my point.

Regards

FrD

Le vendredi 1 juin 2018 13:51:54 UTC+2, PMario a écrit :
>
> On Friday, June 1, 2018 at 1:11:32 PM UTC+2, FrD wrote:
> .... 
>
>> Going back to the put.js saver, what about doing a second "put" request 
>> just after the first one and giving it an URL pointing to a file (to be 
>> created) inside a folder (like "TWBackup") which could be on the same level 
>> as the original file. Same structure as in TW Classic.
>> Would it be a way to go ?
>>
>
> Not really. ... If the TWBackup directory doesn't exist on the server, the 
> client / browser would need to create it first. 
>
> While the "save action" seems to be simple, there is a littlebit going on 
> in the background. 
>
> WebDav is an extension [1] to the HTTP(S) request methods [2]. At the 
> moment we only use 3 HTTP functions: 
>
> - OPTIONS is used to get info about the server. eg: If PUT is allowed.
> - PUT method to write a file back to the server.  
> - HEAD is used to get the ETags
>
> This PUT mechanism is "relatively" simple, if there wouldn't be the ETag 
> handling. 
> It caused quite some headaches 
> <https://github.com/Jermolene/TiddlyWiki5/pull/3230> to get it right for 
> different servers. (apache, nginx, IIS, others). 
>
> ETags are used to identify "overwrite collisions". 
>
> Eg: 
>
>  - User A and user B open the same file at the same time. 
>  - User A modifies the file and saves it back to the server. 
>  - Later user B also modifies the file and wants to save it. -> problem
>
> The problem is, that user B would overwrite the changes from user A. Etags 
> [3] help us to detect this problem. ... 
>
> Similar protections would be needed for a WebDav, server-side backup 
> handling. ... As others point out: Serverside backups should be done 
> server-side. 
>
> That's why I personally prefer "local backups". They are much simpler to 
> handle. 
>
> have fun!
> mario
>
> [1] https://en.wikipedia.org/wiki/WebDAV#Implementation
> [2] 
> https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Request_methods
> [3] https://en.wikipedia.org/wiki/HTTP_ETag
>

-- 
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 tiddlywiki+unsubscr...@googlegroups.com.
To post to this group, send email to tiddlywiki@googlegroups.com.
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/b1245825-0f66-42a7-bf70-d48a20771a13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to