I know that this topic has been raised before. I believe there was a discussion centering around the use of ETags and the possibility of inserting an "etag" element or attribute for each entry in the feed -- which would allow tools to at least do a quick GET rather than a full GET for each entry before editing it.
First a brief intro: I'm Daniel Jalkut and just became responsible for the Mac weblog editing software, MarsEdit. In my new role I've had a crash course in publishing protocols, but am probably still a bit naive. Be gentle :)
I've just read through the APP draft for March 2007 and in general I'm really happy with what I'm learning about APP. Just one thing stood out as a point of concern.
>From Section 10. Listing Collections:
Clients MUST NOT assume that an Atom Entry returned in the Feed is a
full representation of a Member Entry Resource and SHOULD perform a GET
on the URI of the Member Entry before editing.
The behavior of MarsEdit, which I think is typical of many remote editors, is to maintain a working "mirror" of the last N posts on the server. These are full representations of the post, an assumption that is probably inspired by the fact that "getRecentPosts" returns the full content of items.
So what concerns me with APP is that clients will necessarily "double-fetch" all post data in order to comply with the standard. The problem is exacerbated by the fact that MarsEdit and other editors show a "complete preview" of items that the user may wish to edit, so the full representation may be desired even before an actual edit of an item is imminent. Again this luxury is probably inspired by the verboseness of the "getRecentPosts" method.
So to emulate the "complete sync" that I currently get with MetaWeblog and Blogger, I'll have to:
1. Download the complete collection feed.
2. Iterate and download the complete member resource for each item in the collection.
It seems that the situation would be helped by having some way to either download a light-weight index of the collection feed's items (I hope I didn't miss something obvious here), or else to have a clue from the server that in fact the feed's items are full representations.
Given my interpretation of the draft requirement, I think one of two things will happen. Either clients will ignore the standard and assume full representation feeds, or else clients will habitually double-strain the server in order to maintain a reliably full representation copy of the content.
I did search the archives for an existing topic on this subject, but didn't find anything. Hopefully I didn't miss it.
If you know that MarsEdit originally posted the entry, you may have shortcuts as well... especially if the original server POST responses return ETags.
