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

From: Peter Raymond <[email-masked]>
Date: Thu, 3 May 2001 10:31:01 +0100

Hi,

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
content.

We track the last modification time (in UTC) of the file content at check-in
time.
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
etc.
  
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.

Regards, 
--
Peter Raymond - MERANT  
Technical Architect (ADM)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
mailto:[email-masked]
WWW: http://www.merant.com

-----Original Message-----
From: Douglas R. Steen [mailto:[email-masked]]
Sent: Thursday, May 03, 2001 1:41 AM
To: [email-masked]
Subject: RE: File creation date, version creation date, and
getlastmodified

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
  [email-masked]
  Drag-and-Drop Web File Management
  http://www.eKeeper.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Lisa Dusseault
Sent: Wednesday, May 02, 2001 4: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: "Dan Brotsky" <[email-masked]>
Date: Thu, 3 May 2001 10:30:51 -0700

>I am in favor of Lisa's suggestion of having three timestamps.

I'm not sure Lisa was actually making that suggestion :^), but in any 
event I don't like the idea of requiring this kind of timestamping at 
all.  It adds detail to the abstract "DAV resource" that 
unnecessarily biases it towards file-system implementations (where 
content and properties are likely to be stored separately and 
modified independently).

I believe that the modification date property is in DAV because it's 
there in HTTP 1.1.  And its semantics are left vague exactly to allow 
many different implementations.

The move to etags in 1.1 was specifically intended to more generally 
answer the question "has the content of this resource changed."  We 
shouldn't now go back and try to resurrect modification dates as the 
way to find out about content changes.

Similarly, I don't think we should tie modification dates one way or 
the other to property changes. if clients need a way of asking "has 
this resource changed in any way - content or properties" then we 
should add a "property etag" in addition to the "content etag" that 
now exists.

     dan
-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:[email-masked]>