Subject: RE: WRITE_DAV_PROP: Summary of consensus

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 16 Apr 2001 18:03:03 -0400

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:[email-masked]]
Sent: Monday, April 16, 2001 5:26 PM
To: [email-masked]
Cc: [email-masked]
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:[email-masked]]
> Sent: Monday, April 16, 2001 4:27 PM
> To: [email-masked]
> 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"
> 
>                     <[email-masked]>       To:     "WebDAV WG"
> <[email-masked]>
>                     Sent by:                 cc:
> 
>                     w3c-dist-auth-requ       Subject:     WRITE_DAV_PROP:
> Summary of consensus
>                     [email-masked]
> 
> 
> 
> 
> 
>                     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.

---

From: "Steve K Speicher" <[email-masked]>
Date: Tue, 17 Apr 2001 07:50:11 -0400

"Jim Whitehead" wrote:
> Are there other typical uses of touch(1) of which I'm unaware?

FWIW: I've used touch(1) to NOT allow the recompilation using make.  I have
used touch(1) to set the modification time of a file back to what it was
previous to a modification, was when it affected a source file in a build
tree that was on a shared file system (DFS) for multiple platform builds.
Since only a few C++ compilers on some platforms would fail on a certain
file, if I was to fix that one header file then all platform builds would
be out-of-date and need to be rebuilt (or at least be rerun with "make
-t").  To solve this, I would just do a 'touch <previous-mod-time>' on the
header file and make all the prebuilt trees appear to be up-to-date again.

I'm not necessarily advocating supporting this *hack*, I'm just answering
JimW's question.  To get similar behavior like this in DAV, I guess I'd
just have to do something similar to "make -t" to make the builds
up-to-date.

Steve