Subject: Re: [Fwd: draft-reschke-http-addmember-00]

From: Lisa Dusseault <[email-masked]>
Date: Thu, 17 Feb 2005 09:41:55 -0800

On Feb 17, 2005, at 4:58 AM, Stefan Eissing wrote:

>
> I think What Would Make The World A Better Place is a mechanism that 
> generic clients can discover POST service points where they can 
> persist new entities. There is nothing wrong with POST, it is just 
> that a client cannot discover if and where a server supports that 
> feature.
>
> Atom solves this problem by embedding the POST service uri into the 
> feed document. That is fine, but
> a) has low reusablity for other protocols/applications
> b) has no usability from the view of a generic client

Not only that, the Atom approach makes it very difficult for a client 
to synchronize a set of items such as a blog in such a way that the 
blog can be authored offline and synched with both local changes and 
server changes.  It might be possible for a specialized Atom client but 
certainly not for an out-of-the-box WebDAV client.

That's what concerns me for the feature of adding a new resource and 
letting the server choose a location -- it would be nice for a tool 
like Sitecopy to still be able to work.  I'm using that more and more 
to get content to  and from sites like ietf.webav.org.

>
>  I think this is what Julian tries to address with ADDMEMBER, since 
> this method will  be visible in an OPTIONS response. Alternatively, an 
> OPTIONS reponse could carry an extra Header with the URI of such a 
> POST service.

I think ADDMEMBER would be worthwhile if it did have more of an 
extensibility model and provide the ability to support specialized 
applications. For example, some calendar servers need to reject 
non-iCalendar formatted submissions.  ADDMEMBER reminds me a lot of 
MKRESOURCE if it leans in that direction.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Feb 2005 18:49:58 +0100

Lisa Dusseault wrote:
> ...

Well, we just killed MKRESOURCE for good reasons :-)

Anyway; nothing is preventing a server to restrict the applicable 
content types for ADDMEMBER...

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Robert Sayre <[email-masked]>
Date: Thu, 17 Feb 2005 13:00:13 -0500

>> b) has no usability from the view of a generic client

This is not strictly true. I've seen feeds that do that, but the actual 
Atom approach, to the extent that it is nailed down, tends to be a 
service description that points at collections (which are not formally 
defined as WebDAV collections, but could be). For example, you do a GET 
on http://www.blogger.com/atom/, and the resulting document gives you 
URIs of collections corresponding to each of your blogs, based on your 
authentication credentials.

> 
> Not only that, the Atom approach makes it very difficult for a client to 
> synchronize a set of items such as a blog in such a way that the blog 
> can be authored offline and synched with both local changes and server 
> changes.  

Fully agree, but this is a major (and contentious) open issue, and there 
are a variety of ways we can solve it.

> It might be possible for a specialized Atom client but 

That depends on what we come up with.

Atom collections respond to POST in the manner that's been discussed on 
w3c-dist-auth, where it adds a member Atom resource. However, Atom 
servers also respond to POSTed SOAP requests at the same URI, and 
dispatch based on the presence of a SOAP-Action header. I'm sure that 
triggers allergic reactions for some people following this thread, but 
you know what? It works.

Robert Sayre

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 17 Feb 2005 13:18:14 -0500

> certainly not for an out-of-the-box WebDAV client.

There is no possibility for a WebDAV client to work with an
Atom server, so this comment is rather puzzling.

> to get content to  and from sites like ietf.webav.org.

While it might be interesting to compare and constrast Atom and
WebDAV, please realize the Atom Publishing Protocol was 
always intended to be a lightweight protocol that did one thing 
and did it well. 

-joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Robert Sayre <[email-masked]>
Date: Thu, 17 Feb 2005 13:43:31 -0500

[atom-syntax only]

Joe Gregorio wrote:

> WebDAV, 

It sure is, because WebDAV represents an enormous amount of prior art.

> please realize the Atom Publishing Protocol was 

As it stands now, the Atom Publishing Protocol does its core tasks 
badly. You might not like WebDAV, but this WG does not exist to rubber 
stamp RESTlog.

As I've already mentioned, I'm not interested in arguing about religion.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Thu, 17 Feb 2005 13:46:01 -0500

> Atom server, so this comment is rather puzzling.

Fully agree. This is a result of design flaws in the Atom Publishing 
Protocol.

Robert Sayre