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

Let's not try to overload getlastmodified with eTag semantics. There will
be times when live properties change due to side-effects of other
operations. These changes will not result in a new version, but clearly
some clients may want caches to become stale depending on the semantics of
the property and how they might be using it. So they might result in a new
eTag, even if the getlastmodified property didn't change. Implicit in
getlastmodified is often by whom. I suppose the server could be considered
a principal in this regard though.



                                                                                                                 
                    "Lisa Dusseault"                                                                             
                    <lisa@xythos.com>        To:     "Clemm, Geoff" <gclemm@Rational.Com>,                       
                    Sent by:                  <w3c-dist-auth@w3c.org>                                            
                    w3c-dist-auth-requ       cc:                                                                 
                    est@w3.org               Subject:     When to modify getlastmodified  (Was: RE:              
                                              WRITE_DAV_PROP: Summary of consensus                               
                                                                                                                 
                    04/16/2001 06:27                                                                             
                    PM                                                                                           
                                                                                                                 
                                                                                                                 



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 21:53:24 UTC