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

RE: Ideas: GETSRC & MULTIPUT

From: Lisa Dusseault <lisa@xythos.com>
Date: Tue, 30 Oct 2001 09:34:02 -0800
To: "Clemm, Geoff" <gclemm@Rational.Com>, "WebDAV" <w3c-dist-auth@w3.org>
Message-ID: <HPELJFCBPHIPBEJDHKGKKEMDCPAA.lisa@xythos.com>
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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: October 29, 2001 1:55 PM
> To: WebDAV
> Subject: RE: Ideas: GETSRC & MULTIPUT
>
>
> 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:julian.reschke@gmx.de]
> 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: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]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:ejw@cse.ucsc.edu]
> > 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
> >
Received on Tuesday, 30 October 2001 12:35:23 GMT

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