W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2001

RE: Ideas: GETSRC & MULTIPUT

From: Eric Sedlar <Eric.Sedlar@oracle.com>
Date: Mon, 29 Oct 2001 23:53:03 -0800
To: "WebDAV" <w3c-dist-auth@w3.org>
Message-ID: <NDBBLFOFMCKOOMBDHDBKIECACDAA.Eric.Sedlar@oracle.com>
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?

> And the "read" ACL (i.e. everyone 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.

> 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?
> 

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.

> 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.
> 

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
Received on Tuesday, 30 October 2001 02:49:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:58 GMT