RE: WRITE_DAV_PROP: Summary of consensus

Good point.  I should have said "an operation that just sets
the getlastmodified to be the current server time is OK, but
an operation that sets getlastmodified to a client specified
value has the following problems ...".  As you say, touch(1)
does in fact let you set the dates to arbitrary client-specified
values.

Cheers,
Geoff

-----Original Message-----
From: Laurie Harper [mailto:zodiac@holoweb.net]
Sent: Monday, April 16, 2001 5:26 PM
To: w3c-dist-auth@w3.org
Cc: w3c-dist-auth@w3c.org
Subject: Re: WRITE_DAV_PROP: Summary of consensus


Note also that touch(1) is a significantly more powerful tool than the
operation "touch" as you've defined it...  

As remote-file-system type DAV clients become more widespread, I could
imagine lack of mutability of this property could become more contentious...

L.

"Clemm, Geoff" wrote:
> 
> 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

-- 
http: www.holoweb.net/~zodiac/   |   jabber: zodiac(@)jabber!org
email: zodiac(@)holoweb!net      |   icq: #78724820
-----------------------------------------------------------------
   condom: general protection error, child process produced.

Received on Monday, 16 April 2001 18:03:41 UTC