Subject: RE: Ideas: GETSRC & MULTIPUT

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

From: Eric Sedlar [mailto:[email-masked]]

   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.

What about the "DAV:getcontentlength" property?
And the "last accessed" date?
And the "read" ACL (i.e. everyone that
can read the result can read the source)?
And for this kind of resource, you use GETSRC to retrieve what
you just PUT, while for most other resources, you use GET to
retrieve what you just PUT?

In many cases, page caching on the server
means that there commonly are two different files being stored
on the server.  And that sometimes the source file is not even
on the same server as the derived file.

The "separate resource" model seems pretty reasonable to me.

Cheers,
Geoff

---

From: "Eric Sedlar" <[email-masked]>
Date: Mon, 29 Oct 2001 23:53:03 -0800

Geoff, I'm still not buying it.

> What about the "DAV:getcontentlength" property?

This is actually kind of a stupid property for the generated content,
since it is usually impossible to know the length of the data that will
be output before actually generating it.
> And the "last accessed" date?

Is there a DAV: property for that?

> can read the result can read the source)?

Perhaps, GET should be restricted by a dav:get privilege, or else GET
should be restricted by a dav:execute privilege if the contents is 
generated.

> retrieve what you just PUT?

GETSRC will always retrieve what you PUT.  GET is the equivalent of
a doubleclick on a file in windows--it runs some type-dependent "open"
functionality.

> on the same server as the derived file.

Caching generated output may or may not make sense, depending on how
that generation is done.  I think the stretch is treating generated
content as file.  Let's say my .jsp file generates my shopping cart
page from some rows in a database.  You generally don't know the 
length, modification date, or other normal file-like properties for
generated output.  The modification date of the shopping cart is the
time the last item in the cart was modified, and most database applications
don't track this on a per-row basis.

--Eric