- From: jack vamvas-angryfish.uk.com <jack@angryfish.uk.com>
- Date: Thu, 3 May 2001 13:20:56 +0100
- To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org
unsubscribe -----Original Message----- From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com] Sent: Thursday, May 03, 2001 11:49 AM To: ietf-dav-versioning@w3.org; w3c-dist-auth@w3.org Subject: RE: File creation date, version creation date, and getlastmodified Lisa Dusseault wrote: > WebDAV people: RFC2518 leaves it carefully open whether > 'getlastmodified' changes when properties of the resource > change. It seems useful either way -- users might want to > get the last time the content was changed, or they might > want to see the last time the file was touched at all. Is > there some precedent? I seem to recall that moddav does not change the last modified timestamp when properties are updated. There has been discussion on this topic previously, with a weak consensus that the properties should not contribute to last modified changes. I think this is the right answer. Peter Raymond <Peter.Raymond@merant.com> wrote: > One example of why we keep the "last modified" date separate > is that our build system uses this to compare with timestamps > of files on disk to decide if the file is out of date. If the > WebDAV client set the last modification time each time a > property was changed then the build system would think the file > on disk was "out of date" compared to the file held in version > control. I think that this is a common scenario, also found on caching proxies, that relies upon property updates not being considered a change to the resource. Clearly there is some ambiguity here. On the one hand, properties appear to be 'part of' a resource. They appear when a resource is created, and disappear when a resource is deleted. Operations on a property are via the URL of the resource. However, live properties exhibit behaviour that sets them apart from the resource. They can change even when a resource is versioned or locked, and (at least in a couple of implementations) changes to the resource's properties do not change the last modified timestamp of the resource. Lisa Dusseault wrote: > DeltaV people: What does it mean to get the time file content > was last "modified", if the file is versioned? I don't see > that the behaviour of getlastmodified is specified for a > Version-Controlled Resource, can this be a recommendation in > the spec to promote consistency? For one thing, should > 'getlastmodified' on the VCR change when it is checked out, > or when it is checked in, or both? When a version-controlled resource is checked-out its contents and dead properties are updated to be the same as the version identified in the DAV:checked-in property. Therefore the DAV:getlastmodified timestamp clearly should be updated to reflect the changes. Note that the timestamp value is the server's notion of the time the version-controlled resource was modified and not the same as the checked-in version's DAV:getlastmodified. When a version-controlled resource is checked-in, its content and dead properties become those of a new version in the version history. Some live properties of the version-controlled resource are updated to reflect its checked-in status. In this case I argue that the DAV:getlastmodified timestamp does not change. Furthermore, if you use UPDATE to update the content and dead properties of a version-controlled resource to reflect the state of a version in version history, the DAV:getlastmodified timestamp will be the time that the UPDATE method was applied and not that of the version. It it were otherwise updating the version-controlled resource to an earlier version would make the last modified time go 'backwards' which would potentially screw up caching proxies and clients that rely on If-Unmodified-Since: headers etc. > - time the file was last touched What is your definition of touched? Dead property updates? Given the number of live / computed properties I assume you agree that their values do not contribute to the touched timestamp? Regards, Tim Ellison Java Technology Centre, MP146 IBM UK Laboratory, Hursley Park, Winchester, UK. SO21 2JN tel: +44 (0)1962 819872 internal: 249872 MOBx: 270452
Received on Thursday, 3 May 2001 08:31:11 UTC