RE: GETSRC & MULTIPUT

Actually, I did address these requirements with my 5th point.  This was an
example of my "hack" to do what you are talking about with the existing
mod_dav.so.  If you put a .url file that is a link to the original source,
doing a proppatch and propfind on this url file is atomic.  Doing  proppatch
and propfind on the original source is atomic as well.  Doing a put and get
on either should put or get the same source bits.  In my opinion, it should
not be up to the webdav server to decide what to do with those source bits.
This should be proxied through another server or handled by the client.

For example, if I have a resource that has been rotated, the webdav server
shouldn't do the rotation.  This should be done by another server or the
client itself.
@m

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
Sent: Tuesday, October 30, 2001 1:16 PM
To: WebDAV
Subject: RE: GETSRC & MULTIPUT


I'm not sure you really addressed the requirements that Jim has:

* atomic read/write of contents & properties
* getting the source file for generated content vs. getting the generated
output

The notion of symbolic links potentially has the problem where GET doesn't
return the
same stuff as PUT stored, but typically (on a filesystem), you can use
read() to get
the contents you just did a write() on, even if the pathname is a symbolic
link.

I guess I don't see symbolic links (or BINDings in the WebDAV parlance) as
relevant
to this discussion.

-----Original Message-----
From: Adam Freeman [mailto:afreeman@lightsurf.com]
Sent: Tuesday, October 30, 2001 1:03 PM
To: Eric Sedlar; WebDAV
Subject: RE: GETSRC & MULTIPUT

Hello,
1)  new methods (GETSRC, READ, WRITE) should be avoided if possible.  There
are plenty of methods in webdav already.
2)  webdav turns a website into a file system.  What does webdav seem to be
missing?  A good clean concept of a soft link.
3)  what webdav needs is something analogous to a soft link in a file
system.  The soft link resource can have a different set of properties than
the original resource.
4)  if you start from the file system concept, then you think about how
webdav should make this look transparent to the client (just like a soft
link in the file system would look but it might have a different set of
properties on it than another soft link or the original file)
5)  Using webdav currently, I could mimic this by using PUT on a .url file
(that links to the original source) and then using PROPPATCH on that .url
file.  PROPFIND then returns a different set of properties for that .url
file than the original resource but GET returns the original source bits.
This works with mod_dav.so.
@m

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
Sent: Tuesday, October 30, 2001 12:19 PM
To: WebDAV
Subject: RE: GETSRC & MULTIPUT


The fundamental question that must be addressed is whether or not the source
resource and the output resource are the same.  To me, the question boils
down to wanting to have symmetry in my methods.  If I call PROPPATCH, I can
then use PROPFIND to see the properties I just wrote.  We need the same
thing for PUT.  If I call PUT on a URL, I want a method that gets me back
the stuff I just PUT at that URL.

Even if I have a script that handles multiple resources, such as a program
called "foo.pl", that can handle

/cgi-bin/foo.pl

AND

/cgi-bin/foo.pl/werf

the argument doesn't really apply, since generally /cgi-bin/foo.pl/werf will
not respond to PUT or PROPPATCH.  It's not really a WebDAV resource.

Here's what WebDAV really needs:

* a method called READ and a method called WRITE
* The WRITE method can be used to write the dead properties and contents of
a resource in a single atomic transaction.
* The READ method can be used to read the dead properties and contents of
the resource EXACTLY as stored by the most recent PROPPATCH/PUT/ACL/WRITE
method stored them

This would address both of the needs that Jim cites.  We could also be extra
clever and perhaps add another header called Property-Length that specifies
the byte length of the property data within the message body, so that we
don't have to use multipart/mime encoding for the contents (which can be
computationally expensive).

--Eric

Received on Tuesday, 30 October 2001 17:21:33 UTC