Subject: RE: Issue: WRITE_DAV_PROP

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 11 Apr 2001 07:35:12 -0400

My vote:
- protected (i.e. properties that MUST NOT be modifiable with PROPPATCH)
 creationdate
 getcontentlength
 getetag
 getlastmodified
 lockdiscovery
 supportedlock
 resourcetype
- not protected (i.e. properties that MUST be modifiable by PROPPATCH)
 displayname
 getcontentlanguage
 getcontenttype
 source
 
My rationale for DAV:resourcetype is that the resourcetype should be used
to define the inherent nature of a resource (e.g. collection vs.
non-collection), while getcontenttype is definable by the client.

Cheers,
Geoff

-----Original Message-----
From: Jim Whitehead [mailto:[email-masked]]
Sent: Tuesday, April 10, 2001 8:59 PM
To: WebDAV WG
Subject: Issue: WRITE_DAV_PROP

Issue: WRITE_DAV_PROP

Description:

Which properties specified in the WebDAV specification (i.e., "DAV:"
properties) may be written by the client? For example, can the client write
to DAV:getcontenttype?

Jim Davis raised this issue:

http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0204.html

See also:

http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0205.html
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0289.html
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0292.html

- Jim

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 11 Apr 2001 09:52:49 -0700

I agree.

- Jim

---

From: "Kevin Wiggen" <[email-masked]>
Date: Fri, 13 Apr 2001 09:02:25 -0700

I agree also.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jim Whitehead
Sent: Wednesday, April 11, 2001 9:53 AM
To: WebDAV WG
Subject: RE: Issue: WRITE_DAV_PROP

I agree.

- Jim

---

From: Greg Stein <[email-masked]>
Date: Fri, 13 Apr 2001 13:56:06 -0700

Seems fine, but...

I could see an argument for getlastmodified (e.g. "touch" the resource). And
maybe for creationdate for somebody that is restoring documents to a server.
Then you have the "COPY is performed using PROPPATCH" where you may need to
copy all the props.

I'm also a bit leery of the getcontentlanguage and getcontenttype being a
MUST. I'd prefer those be a MAY, and displayname and source remain as MUST.
The basic problem with the language/type is needing to look them up for each
GET from the server. That can seriously impact server performance.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---

From: "John Glavin" <[email-masked]>
Date: Fri, 13 Apr 2001 15:05:32 -0700

I agree about the "getlastmodified" property.  I would love to be able to
set this so that file synchronization software will work properly.  My
product maps a network drive to a DAV server and unless I can set the
"getlastmodified" property file synch software won't work right.  I only
know of one server that allows this now, it would be nice if this could be
standardized.

John Glavin
RiverFront Software
[email-masked]
http://www.webdrive.com

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 16 Apr 2001 12:24:17 -0700

> know of one server that allows this now, it would be nice if this could be

Hmm, it's not at all obvious to me why writing to getlastmodified helps
synchronization. Naively I would think the synchronization algorithm on
resource R would be:

- retrieve getlastmodified and getetag properties on R
- IF local copy of R unchanged AND ((getlastmodified > R file timestamp) OR
(getetag != stored value of R's etag from when it was originally
downloaded)) THEN get file from server & update cached etag value ELSE leave
local copy of R unchanged (it is the latest version)
- IF local copy of R is changed THEN
  - IF (getlastmodified > value of getlastmodified from last download of the
resource) OR (getetag != stored value of R's etag from when it was
originally downloaded) THEN note a conflict, since the file has been updated
on the client and the server
  - ELSE write the client file to the server, since the client file has been
changed, and the server file hasn't

I don't ever see a case here where changing the value of getlastmodified
helps. When writing the client file to the server using PUT, the server
automatically updates getlastmodified.

This synch algorithm does assume that two pieces of metadata are stored for
each resource, on the client side:

- value of getlastmodified from the last download of the resource
- value of getetag from the last download of the resource

- Jim

---

From: "John Glavin" <[email-masked]>
Date: Mon, 16 Apr 2001 16:48:03 -0700

----- Original Message -----
From: "Jim Whitehead" <[email-masked]>
To: "John Glavin" <[email-masked]>; "WebDAV WG"
<[email-masked]>
Sent: Monday, April 16, 2001 12:24 PM
Subject: RE: Issue: WRITE_DAV_PROP

> automatically updates getlastmodified.

This is where the problem lies.  If you PUT  a file to the server, the
server will update getlastmodified.  The way that existing Windows
applications synchronize files is to copy the file to the server and then
set the modified time to match the existing modified time of the file that
is say on the users hard disk.  This way when it next checks to see if the
file is in synch it will just check the last modified property.  I know that
DAV isn't specific to Windows or any file system in particular, but it would
be nice if there was a way in DAV to allow existing file synchronization
software to work.  A simple way to do this is to allow the getlastmodified
property to be set.

The algorithm mentioned above by Jim would work fine if the synchronization
software was written with DAV in mind.  My product maps a network drive
under Windows to a DAV server, so I can't really change the method that
applications use to synchronize files, nor could I expose these additional
DAV properties to them.

The DAV server for www.mydocsonline.com does this and it works very well
with my product and some other products out there that count on this for
file synchronization.

Thanks,

John Glavin
RiverFront Software
http://www.webdrive.com