W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001

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

From: Peter Raymond <Peter.Raymond@merant.com>
Date: Thu, 3 May 2001 10:31:01 +0100
Message-ID: <20CF1CE11441D411919C0008C7C5A13B01D03BA4@stalmail.eu.merant.com>
To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org

I am not sure that properties are necessarily "becoming a true part of the
file", our system is a complete workflow 
based SCM system with build capabilities etc.  WebDAV clients will be using
the same repository/server as the rest of 
our application.  Some of our properties like "workflow state" for example,
are not directly related to the file

We track the last modification time (in UTC) of the file content at check-in
Separately we track the last time the file had any property changed etc,
this includes promoting through the workflow, 
changing properties, locking/unlocking, adding/removing from a collection
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 am in favor of Lisa's suggestion of having three timestamps.

Peter Raymond - MERANT  
Technical Architect (ADM)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
WWW: http://www.merant.com

-----Original Message-----
From: Douglas R. Steen [mailto:dsteen@ekeeper.com]
Sent: Thursday, May 03, 2001 1:41 AM
To: w3c-dist-auth@w3.org
Subject: RE: File creation date, version creation date, and

re: WebDAV.

My vote would be changing getlastmodified when the properties change.  As we
use properties more and more, they become a true part of the file in the
user experience.  Trying to distinguish between the two ("I know you changed
the billing number yesterday, but you didn't change the _content_ so the
date still reads last week...") can be difficult.

Unfortunately, it's a very easy shorthand for server implementations to use
the file last-modified date for getlastmodified, and for the operating
systems I know that reflects the date/time of the last content modification.

  Douglas R. Steen
  Drag-and-Drop Web File Management

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
Sent: Wednesday, May 02, 2001 4:25 PM
To: DeltaV; w3c-dist-auth@w3.org
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?

Received on Thursday, 3 May 2001 05:30:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:22 UTC