Lisa Dusseault wrote:
On Feb 17, 2005, at 4:58 AM, Stefan Eissing wrote:
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
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 certainly not for an out-of-the-box WebDAV client.
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
