- From: Jim Whitehead <ejw@cse.ucsc.edu>
- Date: Mon, 16 Apr 2001 12:24:17 -0700
- To: "John Glavin" <john@riverfrontsoftware.com>, "WebDAV WG" <w3c-dist-auth@w3.org>
John Glavin writes: > I agree about the "getlastmodified" property. I would love to be able to > set this so that file synchronization software will work properly. My > product maps a network drive to a DAV server and unless I can set the > "getlastmodified" property file synch software won't work right. I only > know of one server that allows this now, it would be nice if this could be > standardized. Hmm, it's not at all obvious to me why writing to getlastmodified helps synchronization. Naively I would think the synchronization algorithm on resource R would be: - retrieve getlastmodified and getetag properties on R - IF local copy of R unchanged AND ((getlastmodified > R file timestamp) OR (getetag != stored value of R's etag from when it was originally downloaded)) THEN get file from server & update cached etag value ELSE leave local copy of R unchanged (it is the latest version) - IF local copy of R is changed THEN - IF (getlastmodified > value of getlastmodified from last download of the resource) OR (getetag != stored value of R's etag from when it was originally downloaded) THEN note a conflict, since the file has been updated on the client and the server - ELSE write the client file to the server, since the client file has been changed, and the server file hasn't I don't ever see a case here where changing the value of getlastmodified helps. When writing the client file to the server using PUT, the server automatically updates getlastmodified. This synch algorithm does assume that two pieces of metadata are stored for each resource, on the client side: - value of getlastmodified from the last download of the resource - value of getetag from the last download of the resource - Jim
Received on Monday, 16 April 2001 15:25:55 UTC