Re: WRITE_DAV_PROP: Summary of consensus

Per Geoff's point: mod_dav does *not* update the getlastmodified value when
a property is changed (for the default software config, where stuff is
stored into the filesystem; if you have a custom backend, then who knows).

And all the get* properties are readonly. We determine Content-Language and
Content-Type using standard Apache mechanisms (which don't have to hit a
property database every time).

Cheers,
-g

On Mon, Apr 16, 2001 at 05:53:11PM -0400, Clemm, Geoff wrote:
> 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
> 

-- 
Greg Stein, http://www.lyra.org/

Received on Tuesday, 17 April 2001 01:33:23 UTC