- From: Fuller, Dan (ENW) <Dan.Fuller@enron.com>
- Date: Thu, 8 Nov 2001 13:01:33 -0600
- To: "Jim Whitehead" <ejw@cse.ucsc.edu>, "WebDAV" <w3c-dist-auth@w3.org>
OK. Sounds like a plan. Thanks for clarifying that. If we have that many names to play with, we could have a separate method for package size. ;) Just kidding, thanks again. -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Thu, November 08, 2001 11:36 AM To: Fuller, Dan (ENW); WebDAV Subject: RE: Ideas: GETSRC & MULTIPUT 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 14:01:49 UTC