Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-06.txt

From: Bill de hÓra <[email-masked]>
Date: Thu, 17 Aug 2006 02:02:49 +0100

Mark Nottingham wrote:

> How about:
> 
> [[[
> Archive documents are feed documents that contain less recent entries in 
> the feed. The set of entries contained in an archive document published 
> at a particular URI SHOULD NOT change over time. Likewise, the URI for a 
> particular archive document SHOULD NOT change over time.
> 
> These stability requirements allow clients to make certain assumptions 
> about archive documents; they may safely assume that if they have 
> retrieved the archive document at a particular URI once, it will not 
> meaningfully change in the future.
> ]]]

they may safely assume  -> they can safely assume - ie, this boils to a 
cache directive - any need to specify what one can infer here? You could 
state there are consequences when servers deviate from SHOULD NOT.

But +1, sounds good.

cheers
Bill

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 16 Aug 2006 17:19:15 -0700

On 2006/06/29, at 7:45 PM, James M Snell wrote:
>
> A couple of comments...
>
>
> Section 6
>
>    Archive documents are feed documents that contain less recent  
> entries
>    in the feed.  The set of entries contained in an archive document
>    published at a particular URI MUST NOT change over time.
>
> I definitely understand the motivation for the "MUST NOT" here, but  
> I'm
> not sure if it's enforceable.  For instance, on my blog, I may go back
> and delete an old entry that appears within an archive feed.  Such a
> change should be reflected in the archive feed.  I would recommend
> changing this to a "SHOULD NOT" with a comment that removing entries
> from an archive document has a negative impact on the cacheability of
> the document and the effectiveness of the archive.

How about:

[[[
Archive documents are feed documents that contain less recent entries  
in the feed. The set of entries contained in an archive document  
published at a particular URI SHOULD NOT change over time. Likewise,  
the URI for a particular archive document SHOULD NOT change over time.

These stability requirements allow clients to make certain  
assumptions about archive documents; they may safely assume that if  
they have retrieved the archive document at a particular URI once, it  
will not meaningfully change in the future.
]]]

>
> Section 6.1
>
> The archive document examples do not have the <fh:archive /> element

Fixed; thanks (and to Stefan as well).

--
Mark Nottingham     http://www.mnot.net/

---

From: Andreas Sewe <[email-masked]>
Date: Thu, 17 Aug 2006 13:53:29 +0200

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