RE: File creation date, version creation date, and getlastmodifie d

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