Subject: RE: WRITE_DAV_PROP: Summary of consensus

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

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

---

From: "Eric Sedlar" <[email-masked]>
Date: Mon, 16 Apr 2001 14:10:29 -0700

How would you suggest that it be done--an empty PROPPATCH?

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Clemm, Geoff
Sent: Monday, April 16, 2001 1:51 PM
To: [email-masked]
Subject: RE: WRITE_DAV_PROP: Summary of consensus

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

 

                    "Jim Whitehead"

 

                    04/16/2001 03:20

                    PM

Consensus:

Still under discussion:

  getlastmodified
  getcontenttype
  getcontentlanguage

- Jim

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 16 Apr 2001 14:51:41 -0700

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

The typical uses of touch(1) are to force recompilation when using make, and
to easily create new, empty files.  Use of touch(1) for forcing
recompilation is a hack -- since there is no general purpose property
mechanism in Unix, there was no way to set the "force recompile" property,
and so the timestamp was overloaded with these semantics.

Are there other typical uses of touch(1) of which I'm unaware?

- Jim

---

From: Laurie Harper <[email-masked]>
Date: Mon, 16 Apr 2001 17:25:49 -0400

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.

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