Subject: PacePutDelete Withdrawn

From: Joe Gregorio <[email-masked]>
Date: Mon, 12 Jul 2004 21:36:43 -0400

I initially proposed PacePutDelete[1] 
and now I would like to withdraw it. 

This does *not* mean I support SOAP. I would in the
long run rather have the section on SOAP removed
or broken off into a separate RFC. Regardless of that
I don't believe this Pace offers any advantages over 
what the protocol is today and it has some distinct 
disadvantages.

[1] http://www.imc.org/atom-syntax/mail-archive/msg03048.html

   Thanks,
   -joe

---

From: Tim Bray <[email-masked]>
Date: Wed, 14 Jul 2004 22:54:08 -0700

> and now I would like to withdraw it.

[Speaking as an individual, not co-chair] I dissent strongly on the 
withdrawing of this Pace at this time, and would like to see it go back 
into the "needs revisiting" queue.  We have not yet taken up the 
cluster of issues around SOAP and REST, and until we do, it is 
inappropriate to remove options from consideration. -Tim

---

From: Walter Underwood <[email-masked]>
Date: Thu, 15 Jul 2004 09:52:50 -0700

--On Wednesday, July 14, 2004 10:54:08 PM -0700 Tim Bray <[email-masked]> 
wrote:
> into the "needs revisiting" queue.  We have not yet taken up the cluster
> of issues around SOAP and REST, and until we do, it is inappropriate to
> remove options from consideration. -Tim

I agree. Needs revisiting. Currently, our customers are asking us
about SOAP, but almost none of them are using our existing SOAP
search interface. At present, I see substantial additional cost in
SOAP compliance and very little benefit.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Ken MacLeod <[email-masked]>
Date: 16 Jul 2004 16:55:46 -0500

Another perspective to note about the SOAP fallback and binary
resources: it is my understanding that there are client implementors
who are implementing to the SOAP binding exclusively, for the purpose
of using SOAP stacks to talk to servers, not merely as a fallback if
PUT/DELETE are not available to them.

These developers are affected by using a binary POST/PUT upload that
does not have a SOAP wrapper, at least in the degree that "this" one
tiny bit of Atom protocol must make them revert to using naked HTTP.

I put this in the "if it hurts, don't do that" category, but it is a
use-case nonetheless.

  -- Ken