Subject: PaceResource -1, PaceSimpleResourcePosting +1

From: Tim Bray <[email-masked]>
Date: Thu, 29 Jul 2004 12:50:33 -0700

I think given that the mechanism in PaceSimpleResourcePosting, 
PaceResource (and all the alternatives it describes) are just no longer 
necessary.

Having said that, PaceSimpleResourcePosting contains a bunch of stray 
language about PUT and Delete and WebDAV and so on that really falls 
under other issues.

There's another issue down the road: if we do a SOAP interface, there's 
going to have to be something in it to distinguish between posting an 
entry and posting something that's not an entry.

My preferred outcome on this would be to
1. close PaceResource, and
2. approve the direct-POST mechanism in PaceSimpleResourcePosting and 
ask the protocol-draft editors to find a smooth way to work it into 
that document.

  -Tim

---

From: Robert Sayre <[email-masked]>
Date: Thu, 29 Jul 2004 16:16:53 -0400

> ask the protocol-draft editors to find a smooth way to work it into that 
> document.

+1, as long as the group is comfortable with lots of editing. If so, 
I'll summarize any discrepancies in an email to the list.

Robert Sayre

---

From: Ken MacLeod <[email-masked]>
Date: 29 Jul 2004 15:38:49 -0500

Tim Bray <[email-masked]> writes:

> [...] PaceSimpleResourcePosting contains a bunch of stray language
> about PUT and Delete [...] and so on that really falls under other
> issues.

> [...]
> 2. approve the direct-POST mechanism in PaceSimpleResourcePosting
> and ask the protocol-draft editors to find a smooth way to work it
> into that document.

+1 to PaceSimpleResourcePosting as-is, -1 to removing PUT/DELETE from
it.

PUT and DELETE allow a posted resource to be updated or deleted later
using the Atom editing client.  Supporting only POST means the editing
client must create new resources every time a diagram, audio clip, or
other entry-referenced resource is changed.

  -- Ken

PS. John and I were working on merging PaceNonEntryResources and
PaceSimpleResourcePosting.  The only remaining item was the ability
for the client to manage "static" resources in specified locations,
like templates and stylesheets, as available in existing APIs like the
BloggerAPI.  I can hold on to that and put it in a new Pace.

---

From: "John Panzer" <[email-masked]>
Date: Thu, 29 Jul 2004 13:43:34 -0700

Robert Sayre wrote on 7/29/2004, 1:16 PM:

 > that

+1.  I added the PUT/DELETE language to try to synchronize with other 
proposals.  If the consensus is to separate the issues, that's great.

-John

---

From: Sam Ruby <[email-masked]>
Date: Thu, 29 Jul 2004 16:52:31 -0400

> entry and posting something that's not an entry.

If SOAP 1.1, then content type will be text/xml (preferably with a 
charset specified), and SOAPAction should be set.

If SOAP 1.2, then content type will be application/soap+xml and 
SOAPAction should be set.

If PaceAtomActionHeader, then Atom-Action should be set.

  = = =

But as you say, this is down the road.  Do we need a fallback?  Should 
we cater to the least common denominator?  Is WSDL 1.1 of value today? 
These issues will eventually need to be pried apart and looked at.  But 
preferably not today.

My intent for posting the above is *not* to reopen those threads at this 
point but merely to indicate that supporting POST of binary objects 
without a wrapper is not inconsistent with future support for any of the 
above - with one possible exception: posting atom entries (literally) as 
text/xml using soap 1.1 over a gateway that drops custom headers. 
Perhaps this can be handled, perhaps this combination is not required, 
at any case, I don't think that any of the above should be a reason not 
to support direct posting of simple resources.

- Sam Ruby

---

From: Ken MacLeod <[email-masked]>
Date: 29 Jul 2004 15:55:32 -0500

Ken MacLeod <[email-masked]> writes:

> like templates and stylesheets, as available in existing APIs like
> the BloggerAPI.  I can hold on to that and put it in a new Pace.

Ignore this part.  John and I had already decided to separate the
issue on our way to merging the Paces.

The only remaining portions to be merged were wording and
clarifications.

For example, PaceSimpleResourcePosting doesn't "name" the URI that is
returned from posting the resource.  It's 99% equivalent to the
EditURI returned from posting an atom:entry, except that it's not an
atom:entry resource at the URI.

I suggest the editors also look at PaceNonEntryResources and use their
judgement as to what would help in incorporating
PaceSimpleResourcePosting.

I can then withdraw PaceNonEntryResources or the chairs can call it
closed.

  -- Ken