Subject: RE: Ideas: GETSRC & MULTIPUT

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 29 Oct 2001 16:55:09 -0500

In general, I believe having distinct URL's for different resources
is far superior to defining new methods.  How would you set access
control on the "source" resource?  How would you get the properties of
the "source" resource?  If you have a URL for the source resource,
all this is straightforward ... but if you have something like a GETSRC
method, the only thing you can do with the "source" is get its content.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Monday, October 29, 2001 4:35 PM
To: Clemm, Geoff; WebDAV
Subject: RE: Ideas: GETSRC & MULTIPUT

Geoff,

I'd like to see how the DAV:dst in WebDAV can support what Microsoft is
doing with their Translate header (namely, having the source and the dynamic
content at the same URL).

See also my comments in

<http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0149.html>

Julian

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Monday, October 29, 2001 10:18 PM
> To: WebDAV
> Subject: RE: Ideas: GETSRC & MULTIPUT
>
>
> Why isn't GETSRC just a GET on the DAV:dst of the DAV:source property?
> (If it is just a shorthand for this, I'm against the redundant marshalling
> of this request through a new method).
>
> As for MULTIPUT, that sounds fine to me, but it should be accompanied by
> a MULTIGET, which would allow reading of a resource and its metadata in
> one transaction.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Jim Whitehead [mailto:[email-masked]]
> Sent: Monday, October 29, 2001 3:14 PM
> To: WebDAV
> Subject: Ideas: GETSRC & MULTIPUT
>
>
> I'm interested in the list's thoughts on two ideas for DAV improvements:
>
> The first is to introduce a GETSRC method to support access to the
> unprocessed source of a resource. This would decouple the dynamic response
> of a resource (GET) from its static source (GETSRC).
>
> The second is to introduce the MULTIPUT method to support "PUT with
> PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart MIME
> packages and atomically write them to the server. This would support the
> update of a resource and its metadata in one transaction.
>
> - Jim
>

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 29 Oct 2001 23:03:27 +0100

Well.

There's RFC2518, and there's what Microsoft does.

Has anybody actually *implemented* RFC2518 this way? I haven't seen any
implementation, so I guess it's at a minimum underspecified or nor
particulary well explained...

Julian

> Sent: Monday, October 29, 2001 10:55 PM
> To: WebDAV

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 29 Oct 2001 16:17:35 -0800

These are very good questions.

One possible set of answers:

> control on the "source" resource?

The dav:readsrc privilege.

> How would you get the properties of the "source" resource?

In this model it's not a different resource, so you'd use PROPFIND. If you
want information about the src, then dav:srccontentlength, dav:srcetag,
dav:srccreationdate, dav:srclastmodified... properties would need to be
defined.

- Jim

---

From: Alan Kent <[email-masked]>
Date: Tue, 30 Oct 2001 14:08:29 +1100

> dav:srccreationdate, dav:srclastmodified... properties would need to be

I would find this hard to swallow. I am uncomfortable about a CGI-BIN
script and the output of the script being called the same resource in
WebDAV. All of WebDAV would have to be carefully reworked to get this
concept in. And what about CGI-BIN scripts which took parameters
or things from the URL? The following URLs could all be the same
CGI-BIN script

    /cgi-bin/foo
    /cgi-bin/foo/bar
    /cgi-bin/foo?name=bar

Does GETSRC on all three return the same CGI-BIN script? Does a LOCK
on /cgi-bin/foo also lock the other two as well? etc. I just feels
messy to me.

I personally think the output of a script and the script itself
are different resources. DeltaV for example uses different URLs
for all the version resources etc. Using a different scheme
suddenly in WebDAV feels against the grain.

Alan

---

From: "Eric Sedlar" <[email-masked]>
Date: Mon, 29 Oct 2001 19:11:13 -0800

The fact that you can't do anything with the source is kind of specious.
You can view the "GET" method as "execute the OPEN action on this resource"
and GETSRC as the get (that gives you the data you just PUT into the
resource).  Anything other than GET that you do to the "source" resource
will operate in the same way as on the original resource, so I think that
using another resource is a poor model.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Clemm, Geoff
Sent: Monday, October 29, 2001 1:55 PM
To: WebDAV
Subject: RE: Ideas: GETSRC & MULTIPUT

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Monday, October 29, 2001 4:35 PM
To: Clemm, Geoff; WebDAV
Subject: RE: Ideas: GETSRC & MULTIPUT

Geoff,

See also my comments in

Julian

---

From: "Dylan Barrell" <[email-masked]>
Date: Tue, 30 Oct 2001 09:17:59 -0500

This gets into the realm of renditions...

I agree with Geoff, alternative renditions of a resource should be different
URLs, however we should define mechanisms for creatung these renditions from
the original resource (perhaps the concept of a "master" resource and
related "renditions") and being able to determine the master and the
renditions from the properties on each.

--Dylan

> Sent: Monday, October 29, 2001 4:55 PM
> To: WebDAV

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 30 Oct 2001 09:34:02 -0800

You know, you can turn that idea on its head and it makes sense.  With
dynamic content and something like a GETSRC method, the only thing you can
do with the dynamically-generated content is GET it.

This is the way a lot of dynamic content actually seem to work:  e.g. the
file is the .jsp file, the "real" content of the file is pretty much the
source code.  Permissions on the .jsp file determine who can read or write
it.  With this view of things, PROPPATCH, PROPFIND, PUT all affect the .jsp
file.  The only thing that differs between a .jsp file and a .txt file in
the same directory is that an innocent GET request returns dynamic content
in the .jsp case.

I agree that when dynamic content is generated certain other ways, e.g.
multiple source files which compile together to form a program that is run
out of cgi-bin, the situation is much different.  Both GETSRC and the
Microsoft solution (translate header) are not very well suited to the
multiple-source-file solution on the face of it.  I guess it's an issue that
sometimes it makes most sense to use the same URL for both source and
result, and sometimes it makes most sense not to.

lisa

> Sent: October 29, 2001 1:55 PM
> To: WebDAV

---

From: "Eric Sedlar" <[email-masked]>
Date: Tue, 30 Oct 2001 12:19:27 -0800

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

---

From: "Adam Freeman" <[email-masked]>
Date: Tue, 30 Oct 2001 13:03:03 -0800

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Eric Sedlar
Sent: Tuesday, October 30, 2001 12:19 PM
To: WebDAV
Subject: RE: GETSRC & MULTIPUT

/cgi-bin/foo.pl

AND

/cgi-bin/foo.pl/werf

--Eric

---

From: "Eric Sedlar" <[email-masked]>
Date: Tue, 30 Oct 2001 13:15:59 -0800

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:[email-masked]]
Sent: Tuesday, October 30, 2001 1:03 PM
To: Eric Sedlar; WebDAV
Subject: RE: GETSRC & MULTIPUT

Hello,

-----Original Message-----

/cgi-bin/foo.pl

AND

/cgi-bin/foo.pl/werf

--Eric

---

From: "Adam Freeman" <[email-masked]>
Date: Tue, 30 Oct 2001 14:04:49 -0800

BIND does not behave like a softlink.  BIND binds all properties from the
linked resource to the original and vice versa.  I just went to explorer,
created a shortcut to a file.  The created date on the shortcut is different
than on the original.  My point is there should be some properties that can
be different on the softlink than on the original and I do not think BIND
provides for that.  Redirect references suck because the server has to issue
a 302 and the client has to make another roundtrip.  This could be a problem
especially for low network latency and bandwidth situations.  I think there
was some other kind of reference that would do the trick (indirect reference
or something like that) but as far as getting this implemented within RFC
2518???  The link property that is part of RFC 2518 should do what I'm
talking about.  The only question is which properties are malleable between
the softlink and the original.
@m

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Eric Sedlar
Sent: Tuesday, October 30, 2001 1:16 PM
To: WebDAV
Subject: RE: GETSRC & MULTIPUT

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

Hello,

-----Original Message-----

/cgi-bin/foo.pl

AND

/cgi-bin/foo.pl/werf

--Eric

---

From: "Jim Whitehead" <[email-masked]>
Date: Tue, 30 Oct 2001 14:02:21 -0800

Lisa Dusseault writes:
> it.  With this view of things, PROPPATCH, PROPFIND, PUT all
> affect the .jsp file.  The only thing that differs between a .jsp file
> and a .txt file in the same directory is that an innocent GET request
> returns dynamic content in the .jsp case.

Yes, this is what I had in mind for GETSRC.

- Jim

---

From: "Adam Freeman" <[email-masked]>
Date: Tue, 30 Oct 2001 14:21:27 -0800

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: Adam Freeman [mailto:[email-masked]]
Sent: Tuesday, October 30, 2001 1:03 PM
To: Eric Sedlar; WebDAV
Subject: RE: GETSRC & MULTIPUT

Hello,

-----Original Message-----

/cgi-bin/foo.pl

AND

/cgi-bin/foo.pl/werf

--Eric

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 30 Oct 2001 16:22:54 -0800

> the stuff I just PUT at that URL.

GET already provides that -- if you can successfully invoke PUT on a
resource, then a GET on that same resource will be the stuff that you PUT
(assuming no other actions occurred in-between).

However, PUT is not allowed on many resources, specifically those resources
that only exist as a synthesis of other resources.  The source links, which
were present in the original HTTP/1.1 proposal and later transformed into
a property in 2518, tell the client how it can edit that resource given that
authoring on the same URI is not possible, period.

....Roy

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 31 Oct 2001 01:33:12 +0100

> [mailto:[email-masked]]On Behalf Of Roy T. Fielding
> Sent: Wednesday, October 31, 2001 1:23 AM
> To: Eric Sedlar
> Cc: WebDAV
> Subject: Re: GETSRC & MULTIPUT
>
>

Well, that's interesting to know, but -- from looking at RFC2518 this is
just "hear-say". What you say makes sense, but it's certainly not what
RFC2518 says (or doesn't say: that when a resource has a source property it
can't be PUT to).

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 30 Oct 2001 16:53:20 -0800

> RFC2518 says (or doesn't say: that when a resource has a source property it

It is theoretically possible for a synthetic resource to be edited by
GET and PUT of its representation, assuming that the server is smart
enough to derive the individual source changes from the modified
representation.  However, that is not an issue, since from the client's
perspective it seems to be editing a static representation.  The whole
point of the source links is to allow the server to tell the client
that "Hey, I'm not smart enough to figure out editing on this interface,
you need to go over to this list of things and edit them individually."
That is a condition of interoperability that is necessary to communicate
between the server and client due to the nature of Web resources.

There are other conditions in which the source URI would differ from the 
"normal" GET URI, such as when authoring is only allowed on a staging
server.  In those cases as well, a GETSRC method or Translate header field
simply will not work.  I cannot understand why it would even be considered.

I am sure that the RFC can be improved to spell this out in more detail,
but that is not unusual for this stage of the standardization process.

....Roy

It doesn't say that, and nothing I said implies it would.  You are reversing
the implication of what I said, which isn't valid logic.

---

From: "Dylan Barrell" <[email-masked]>
Date: Wed, 31 Oct 2001 10:05:47 -0500

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

> Sent: Tuesday, October 30, 2001 4:16 PM
> To: WebDAV