RE: GETSRC & MULTIPUT

In order to frame this discussion of what we need to do we need to agree on
the requirements.

So lets step up a level and talk about the requirements that need to be met
before we get embroiled in a discussion on implementation as most of these
arguments could then be settled by referring back to the requirements.

@Jim - how to we proceed on this type of activity?

--Dylan

> -----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 4: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 Wednesday, 31 October 2001 10:07:05 UTC