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

Re: Listing Collections & Forbidden Assumptions


On 3/12/07, Daniel Jalkut <jalkut@xxxxxxxxxxxxxxx> wrote:



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.


True, but you should only need to do that once. Once you have
each entry you can start leveraging HTTP caching for each of
those resources (etags/cache-control).

When you restart, if you want to re-sync, the collection feed is ordered
by "atom:updated" so you just need walk back through the collection
and GET each entry until you hit one that hasn't changed.

At least that's the way it could work, if collections were actually
ordered by "atom:updated", unfortunately, in Section 10 we have [1]:

 """
 The Entries in the returned Atom Feed SHOULD be ordered by
  their "atom:updated" property, with the most recently updated Entries
 coming first in the document order.
"""

Between the fact that it's a SHOULD and not a MUST, and the
completely useless definition of "atom:updated", you actually
can't count on that working.

Of course, we have "app:edited",  which is precisely defined to be
useful, but collections aren't ordered by "app:edited", and
so "app:edited" sits in the spec, unused and never mentioned
outside its definition.


 [1] http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-14.html#listing-collections

   -joe

--
Joe Gregorio        http://bitworking.org