W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001

RE: WRITE_DAV_PROP: Summary of consensus

From: Clemm, Geoff <gclemm@rational.com>
Date: Mon, 16 Apr 2001 18:03:03 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E2369@SUS-MA1IT01>
To: w3c-dist-auth@w3.org
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


-----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...


"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.
> the modified date on a resource so dependent relationships are processed
> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:22 UTC