When to modify getlastmodified (Was: RE: WRITE_DAV_PROP: Summary of consensus

And that, in itself, is another issue.  Can there be any consensus on what
operations should affect getlastmodified automatically?
 - Body updates surely...
 - Update of dead properties?
 - Conversion of resource to versioned resource or other drastic change?

Similarly, what does getlastmodified on a collection mean?

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Monday, April 16, 2001 2:53 PM
> To: w3c-dist-auth@w3c.org
> Subject: RE: WRITE_DAV_PROP: Summary of consensus
>
>
> Actually, I didn't suggest how it should be done,
> just how it shouldn't be done (:-).  An empty
> PROPPATCH is a possibility, but some servers do
> no have property modifications affect the getlastmodified
> time (only content modifications).
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Eric Sedlar [mailto:eric.sedlar@oracle.com]
> Sent: Monday, April 16, 2001 5:10 PM
> To: w3c-dist-auth@w3c.org
> Subject: RE: WRITE_DAV_PROP: Summary of consensus
>
>
> How would you suggest that it be done--an empty PROPPATCH?
>
> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Monday, April 16, 2001 1:51 PM
> To: w3c-dist-auth@w3c.org
> Subject: RE: WRITE_DAV_PROP: Summary of consensus
>
>
> Note though that updating getlastmodified is a significantly
> more powerful operation than "touch".  Touch just says to act
> as if you wrote the same content over again, i.e. the only
> effect it has on getlastmodified is to reset it to the "current"
> date.
>
> On the other hand, updating getlastmodified lets you roll
> backward in time, thereby potentially breaking the various
> caching schemes that depend on a one-way movement of the
> getlastmodified value.  Note also that even if you intended
> on just "rolling time forward", a client can't really get
> the time "right", so it will set the time either "too early"
> (i.e. earlier than "current") or "too late" (i.e. sometime
> in the future).  Either of these situations can break the
> caching uses of getlastmodified.  In particular, suppose
> you are writing a "too early" time ... if someone previously
> wrote to the resource, which updated the getlastmodified
> time to a time later than your "too early" time,
> then you will roll back the time (potentially breaking
> some caching).  Now suppose you write a "too late" time.
> Then someone does an update, which sets the getlastmodified
> time to a "current" which is earlier than the time you set.
> Again, a "time rollback" has occurred, and you can break
> some caching.
>
> So, although I am in favor of "touch" functionality, I am
> (strongly) against providing it via a writeable "getlastmodified".
>
> Cheers,
> Geoff
>
>
> -----Original Message-----
> From: Jim Amsden [mailto:jamsden@us.ibm.com]
> Sent: Monday, April 16, 2001 4:27 PM
> To: w3c-dist-auth@w3c.org
> Subject: Re: WRITE_DAV_PROP: Summary of consensus
>
>
> getlastmodified needs to be updatable to do a UNIX-like touch
> command. Sets
> the modified date on a resource so dependent relationships are
> processed by
> builders or make.
>
>
>
>
>
>                     "Jim Whitehead"
>
>                     <ejw@cse.ucsc.edu>       To:     "WebDAV WG"
> <w3c-dist-auth@w3.org>
>                     Sent by:                 cc:
>
>                     w3c-dist-auth-requ       Subject:     WRITE_DAV_PROP:
> Summary of consensus
>                     est@w3.org
>
>
>
>
>
>                     04/16/2001 03:20
>
>                     PM
>
>
>
>
>
>
>
>
> Let me see if I can summarize the points of consensus on this issue:
>
> Consensus:
>
> - protected (i.e. properties that MUST NOT be modifiable with PROPPATCH)
>   creationdate
>   getcontentlength
>   getetag
>   lockdiscovery
>   supportedlock
>   resourcetype
>
> - not protected (i.e. properties that MUST be modifiable by PROPPATCH)
>   displayname
>   source
>
> Still under discussion:
>
>   getlastmodified
>   getcontenttype
>   getcontentlanguage
>
> There are two open issues:
>
> 1. Changing get* properties requires the server to perform a property
> lookup
> when processing a GET method request, and this is a performance hit for
> some
> servers.
>
> 2. It is unclear why getlastmodified needs to be writeable.
>
> Let's see if we can resolve these remaining issues over the next 1-2 days,
> so we can wrap this one up.
>
> - Jim
>
>

Received on Monday, 16 April 2001 18:29:02 UTC