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

From: "Harris, Matt" <[email-masked]>
Date: Wed, 2 May 2001 15:11:22 -0700

I am an implementer, not a developer, but I do have an opinion on this one.

For process workflow applications, it is very important to know when the
resource is last changed.  I care less about property changes, although that
event is key for backup software.  I would like to see both tracked.

As far as versioning is concerned, it will often be important to know both
when Check-out occurred and when Check-in occurred, however, getlastmodified
should only reflect Check-in.  This is because the resource has not been
modified, as far as DAV is concerned, until that Check-in has occurred.  To
keep this consistent with the three properties you listed, getlasttouched
would reflect the Check-out event because the file lock was set, while
getlastmodified would not.  On Checked-in both would be updated.

Matt Harris

> -----Original Message-----
> From: Lisa Dusseault [mailto:[email-masked]]
> Sent: Wednesday, May 02, 2001 2:25 PM
> To: DeltaV; [email-masked]
> Subject: File creation date, version creation date, and 
> getlastmodified
> 
> 
> 
> 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?  Really, one might best be served by a new timestamp
> property, so the suite of timestamp-like properties would be
>  - creationdate
>  - time the content was last modified (etag changes, but etag doesn't
> provide a timestamp)
>  - time the file was last touched
> 
> Which one of the last two is most commonly handled by getlastmodified?
> Implementors speak up?
> 
> 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?
> 
> lisa
>

---

From: "jack vamvas-angryfish.uk.com" <[email-masked]>
Date: Thu, 3 May 2001 13:20:56 +0100

unsubscribe

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 03, 2001 11:49 AM
To: [email-masked]; [email-masked]
Subject: RE: File creation date, version creation date, and
getlastmodified

Lisa Dusseault wrote:

> '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 <[email-masked]> 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
> 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

---

From: "Harris, Matt" <[email-masked]>
Date: Thu, 3 May 2001 12:43:03 -0700

Now that is the best suggestion I have seen yet for this issue.

Matt

> From: Adam Freeman [mailto:[email-masked]]
> Sent: Thursday, May 03, 2001 12:04 PM
> To: Douglas R. Steen; [email-masked]
> 
> Hello,
> why not have two different last modified dates, one for the 
> content and one
> for the metadata?
> - Adam

---

From: [email-masked]
Date: Thu, 3 May 2001 14:27:42 +0100

'cmon, it wasn't that bad <g>

try sending your request to
     [email-masked]
and/or    [email-masked]

Tim

"jack vamvas-angryfish.uk.com" <[email-masked]> wrote:

unsubscribe

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 03, 2001 11:49 AM
To: [email-masked]; [email-masked]
Subject: RE: File creation date, version creation date, and
getlastmodified

<<snip>>

---

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 3 May 2001 21:19:46 -0400

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: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 03, 2001 6:49 AM
To: [email-masked]; [email-masked]
Subject: RE: File creation date, version creation date, and
getlastmodified

Regards,

Tim Ellison