Subject: RE: Ideas: GETSRC & MULTIPUT

From: Herbert Bock <[email-masked]>
Date: Thu, 8 Nov 2001 10:07:14 +0100

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:[email-masked]]
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:[email-masked]]
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:[email-masked]]
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:[email-masked]]
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 [email-masked] 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. 
**********************************************************************

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 8 Nov 2001 09:35:55 -0800

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.

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Herbert Bock
> Sent: Thursday, November 08, 2001 1:07 AM
> To: Herbert Bock; 'Fuller, Dan (ENW)'; WebDAV