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

RE: Ideas: GETSRC & MULTIPUT

From: Jim Whitehead <ejw@cse.ucsc.edu>
Date: Thu, 8 Nov 2001 09:35:55 -0800
To: "'Fuller, Dan \(ENW\)'" <Dan.Fuller@enron.com>, "WebDAV" <w3c-dist-auth@w3.org>
Message-ID: <AMEPKEBLDJJCCDEJHAMIEECKDLAA.ejw@cse.ucsc.edu>
My concern with re-using PUT is that existing servers typically take the
request entity body and write it byte-for-byte into a file. They do *not*
check to see if it is a multipart package, instead they happily write bytes,
and return a 200 or 201 (the same codes a multipart-augmented PUT would
return).

So, I think overloading PUT would result in poor interoperability.

- Jim

PS - It's OK to define new methods. Sure, the method name space is flat.
But, even if you limit method names to 10 characters, that's still 32^10
possible name combinations, of which we have used around 25.

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Herbert Bock
> Sent: Thursday, November 08, 2001 1:07 AM
> To: Herbert Bock; 'Fuller, Dan (ENW)'; WebDAV
> Subject: RE: Ideas: GETSRC & MULTIPUT
>
>
> I clarified with Dan what he meant with additional
> parameters for PUT and GET. The point is: isn't it
> possible to extend the definition of PUT to also supply
> the MULTIPUT feature instead of defining a new method?
> I actually would also feel more comfortable with this
> solution but I'm not sure if this is possible? Is it?
>
> Regards,
> Herbert
>
>
> -----Original Message-----
> From: Herbert Bock [mailto:herbert.bock@ixos.de]
> Sent: Dienstag, 6. November 2001 12:31
> To: 'Fuller, Dan (ENW)'; WebDAV
> Subject: RE: Ideas: GETSRC & MULTIPUT
>
>
> Hi Dan,
>
> could it be that you misunderstand the MULTIPUT as a
> PUT of more than one file? The MULTIPUT was meant as
> an atomic update of a resource and its related meta
> data.
>
> Regards,
> Herbert
>
> -----Original Message-----
> From: Fuller, Dan (ENW) [mailto:Dan.Fuller@enron.com]
> Sent: Montag, 5. November 2001 16:03
> To: Herbert Bock; WebDAV
> Subject: RE: Ideas: GETSRC & MULTIPUT
>
>
> Am I the only one who gets queazy about MULTIPUT?  We have well
> implemented DIR and COPY commands in DOS that accept multiple
> parameters.  Why not just extend PUT and GET to accept multiple
> parameters?
>
> -----Original Message-----
> From: Herbert Bock [mailto:herbert.bock@ixos.de]
> Sent: Mon, November 05, 2001 4:41 AM
> To: WebDAV
> Subject: RE: Ideas: GETSRC & MULTIPUT
>
>
> Perhaps I'm a bit late with my comment but I just now read
> Jim's suggestions. Especially the MULTIPUT feature is
> one that I missed very very much when I recently read RFC2518
> and tried to map the functionality of our systems to WebDAV.
> I think MULTIPUT is vital for many scenarios and it is
> quite easy to implement on the server side but extremely
> hard if not impossible on the client side.
>
> Please, please add this feature to WebDAV. I'm sure its
> desperately needed. And many thanks to Jim for triggering
> this.
>
> Regards,
> Herbert
>
> -----Original Message-----
> From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]
> Sent: Montag, 29. Oktober 2001 21:14
> 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
>
>
>
> **********************************************************************
> This e-mail is the property of Enron Corp. and/or its relevant
> affiliate and
> may contain confidential and privileged material for the sole use of the
> intended recipient (s). Any review, use, distribution or disclosure by
> others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive for the recipient), please contact the
> sender or reply
> to Enron Corp. at enron.messaging.administration@enron.com and delete all
> copies of the message. This e-mail (and any attachments hereto) are not
> intended to be an offer (or an acceptance) and do not create or evidence a
> binding and enforceable contract between Enron Corp. (or any of its
> affiliates) and the intended recipient or any other party, and may not be
> relied on by anyone as the basis of a contract by estoppel or otherwise.
> Thank you.
> **********************************************************************
>
Received on Thursday, 8 November 2001 12:40:02 GMT

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