[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Idioms


Joe Gregorio wrote:


I've seen thoughts on this divide down into two basic camps, those that believe if it's a list we
should use the Atom Syndication Format, and
there are those that believe we can use other
formats if the nature of the list diverges too far
from that of a list of 'entries'.

Questions:
1. Do others see the same pattern?

Almost. I see one resource where you see two. That is, the FeedURI and the PostURI are the same thing.

I also think the "list" idiom is inappropriate, because there isn't much justification for a given sequence, especially for users, templates, and other non-entry resources. They are not ordered collections.

2. How to we incorporate this observation into the protocol spec?
    Maybe outline the idiom at the beginning and then
    as we cover each part of the protocol say whether
    it follows this idiom?

Yes, we need to do this. See below.

3. Do we need to reach a concensus on the reuse
of the syndication format before moving forward
on the rest of the items so we don't end up rehashing the same arguement for every part of the
protocol that falls into the List Management idiom?

Well, let's face it. There are really only two games in town. There's the feed format, and there's WebDAV collections. Otherwise, we are inventing something entirely new, and we are unlikely to be very successful.

I've made fairly clear that I am not a big fan of reusing the feed format, so let me explain the benefits of borrowing a bit from WebDAV.

WebDAV is not perfect for us, but I believe we can wedge a resource called an "Atom Collection" in between HTTP and WebDAV. There are two areas where WebDAV doesn't cut it for us. The first is that DAV collections don't define a response to GET. Atom Collections are not dark matter[0], we need GET, and we are free to define it. Second, we need a way to create new resources in a server-specific way that may mangle the state of the POSTed entity. PUT is a bad fit. We will use POST because we are unlikely to distill this process to a more concrete verb or series of transactions.

So, the question is, what burden are we placing on collection resources with regard to WebDAV? Not much, because I don't think we should require Atom Collections to be DAV compliant. Fortunately, WebDAV specifically allows this:

"A resource MAY be a collection but not be WebDAV compliant. That is, the resource may comply with all the rules set out in this specification regarding how a collection is to behave without necessarily supporting all methods that a WebDAV compliant resource is required to support. In such a case the resource may return the DAV:resourcetype property with the value DAV:collection but MUST NOT return a DAV header containing the value "1" on an OPTIONS response."[1]

So, an Atom Collection might be WebDAV Collection, but that would not be required. That way, people who want to do complicated things with Atom resources (e.g. LOCK them) have a well-tested, widely-deployed way to do it. No further Atom work need take place.

Robert Sayre

[0] http://www.intertwingly.net/stories/2002/07/20/restSoap.html#darkMatter

[1] http://asg.web.cmu.edu/rfc/rfc2518.html#sec-5.2