- From: Lisa Dusseault <lisa@xythos.com>
- Date: Mon, 16 Apr 2001 15:27:47 -0700
- To: "Clemm, Geoff" <gclemm@rational.com>, <w3c-dist-auth@w3c.org>
And that, in itself, is another issue. Can there be any consensus on what operations should affect getlastmodified automatically? - Body updates surely... - Update of dead properties? - Conversion of resource to versioned resource or other drastic change? Similarly, what does getlastmodified on a collection mean? > -----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 2:53 PM > To: w3c-dist-auth@w3c.org > Subject: RE: WRITE_DAV_PROP: Summary of consensus > > > 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 > >
Received on Monday, 16 April 2001 18:29:02 UTC