Hi Mark, hi everyone,
(I have Cc'ed this to atom-protocol, too, since it is about an
implementation of both Feed History and APP.)
So let's consider a scenario where both APP and Feed History are to be
implemented. But, to reduce server load, as many documents as possible
are to be served statically.
Now this could be done as follows for an APP Collection whose collection
URI is <http://example.com/feed/current>. This URI would also serve as
the feed's subscription URI. (Furthermore the APP Collection supports
collection paging, and is hence a Paged Feed as per Feed History, too.)
(Well, I said "could be done" -- according to my understanding of both
Feed History and APP, but I might very well be wrong. That's why I want
to hear your opinion on it. ;-)
Focusing on the retrieval of the logical feed or collection for the
moment, let's consider the following protocol exchange:
GET http://example.com/feed/current HTTP/1.1
[...]
HTTP/1.1 307 Temporary Redirect
Location: http://example.com/feed/2006-08
[...]
GET http://example.com/feed/2006-08 HTTP/1.1
[...]
<feed>
<id>http://example.com/feed</id>
<link rel="current" href="http://example.com/feed/current"; />
<!-- Uses *prev*-archive per Feed History I-D -->
<link rel="prev-archive" href="http://example.com/feed/2006-07"; />
<!-- Uses *next* per APP -->
<link rel="next" href="http://example.com/feed/2006-07"; />
<entry>
<id>http://example.com/entry/one</id>
<updated>2006-08-16T12:55:00</updated>
<app:modified>2006-08-16T12:55:00</app:modified>
</entry>
</feed>
GET http://example.com/feed/2006-07 HTTP/1.1
[...]
HTTP/1.1 200 OK
[...]
<feed>
<fh:archive />
<id>http://example.com/feed</id>
<link rel="current" href="http://example.com/feed/current"; />
<!-- Uses *next*-archive per Feed History I-D -->
<link rel="next-archive" href="http://example.com/feed/2006-08"; />
<!-- Uses *previous* per APP -->
<link rel="previous" href="http://example.com/feed/2006-08"; />
<entry>
<id>http://example.com/entry/one</id>
<updated>2006-07-20T14:00:00</updated>
<app:modified>2006-07-20T14:00:00</app:modified>
</entry>
<entry>
<id>http://example.com/entry/one</id>
<updated>2006-07-01T07:30:00</updated>
<app:modified>2006-07-01T07:30:00</app:modified>
</entry>
</feed>
Now what happens when entries are created or modified via the APP?
Whenever an entry is created it is simply added to the "current" page.
But whenever an entry is modified the modified entry is added to the
atom:feed page for the current month, too; less recent revisions of the
entry are *not* removed unless the current page would then contain the
modified entry twice with the *same* app:updated timestamp (but
different app:modified timestamps, of course) since that is forbidden
per RFC 4287.
So every POST or PUT only ever modifies the "current" page. Obsolete
revisions of an entry are simply hidden by their more recent counterparts.
Now what is nice about using monthly archive documents as above is that
you never need to change the archived page once the corresponding month
is over; all archived documents can be served statically. This is
because the atom:links to the "next"/"prev-archive" and to the
"previous"/"next-archive" pages won't change at all (the month before
August 2006 being always July 2006 :-). And the "current" atom:link
needs not to be changed either, thanks to HTTP's temporary redirection.
Note, however, that the second atom:feed page at
<http://example.com/feed/2006-07> contains the atom:entry with atom:id
<http://example.com/entry/one> twice but with different atom:updated
timestamps. Only insignificant changes (only app:modified changes, not
atom:updated) are overwritten by more recent insignificant changes. Each
significantly changed entry is preserved in both the subscription and
archive documents.
OK, I hope I was able to describe my implementation clearly enough. Now
here is my question: Is it broken? ;-)
What still looks dubious to me is the directionality of
"previous"/"next" and "next-archive"/"prev-archive". Did I get that one
right? It looks rather strange with "next" and "prev-archive" pointing
to the same document.
Also I am not sure whether it is alright per Feed History when an
subscription or archive document contains an entry more than once,
although with different atom:updated timestamps. Mark, are there any
problems with this?
Regards,
Andreas Sewe
