- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 3 May 2001 21:19:46 -0400
- To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org
I agree with Tim's position. The DAV:getlastmodified property is explicitly defined to coincide with the value of the Last-Modified header, which is used to control caching of resource content (i.e. what GET returns). Requiring that this date change whenever a property changes would severely harm existing HTTP clients which depend on Last-Modified for content caching. This would be especially disastrous for a server that maintains a "last-accessed" property on resources, since if we stated that a property change causes a Last-Modified change, the DAV:getlastmodified would change every time a resource is accessed. On the other hand, many implementations depend on the underlying "modification date" being maintained by the underlying repository (to allow multi-protocol access to that repository), and for those implementations that store some properties in the repository item that affects the modification date, the modification date on those servers will be affected by a change to those properties. So I believe the current RFC-2518 language is correct and appropriate. Cheers, Geoff -----Original Message----- From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com] Sent: Thursday, May 03, 2001 6: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 21:17:39 UTC