RE: Ideas: GETSRC & MULTIPUT

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