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

From: Thomas Broyer <[email-masked]>
Date: Wed, 20 Jul 2005 19:44:18 +0200

This mail has been around in my drafts folder for about 10 days, but 
here it is...

I'm not sure what my position is wrt what I wrote below...

Mark Nottingham wrote:
> 
> On 04/07/2005, at 6:18 PM, Thomas Broyer wrote:

>> With the -01 draft (it might have been the same within the -00 one  
>> too), one can't reuse the process to link to archives of "Top  
>> Twenty Records" or "Most Popular Items" (e.g. a monthly "Top Twenty  
>> Records" linking to the previous-month "Top"), because of the "a  
>> subscription document whose fh:stateful element contains "false"  
>> MUST NOT contain a fh:prev element".
>> Why not just stating that if fh:stateful is false then the "prev"- 
>> linked archive feed doesn't not contain a subset of the previous  
>> entries but rather does contain the previous state of the  
>> subscription feed. I.e. the meaning of the fh:prev "link" depends   on
>> the value of fh:stateful.
> 
> That's interesting, but it somewhat changes the semantics of "prev";  
> it goes from "where you can find previous entries in a logical feed"  
> to "where you can find an older archive of entries." While these are  
> often the same thing, it might not always be the case; i.e., someone  
> might want to publish a non-time-based feed.
> 
> So, I'm nervous about having two different semantics for one element,  
> depending upon its context of use.

I fully understand (that's actually also somehow bothering me).

I was actually wondering why non-stateful feeds couldn't have archives:
in the "This month's Top 10 records" feed, why couldn't I link to "Last
month's Top 10 records"?
If this kind of links are not dealt within feed-history, then I suggest
splitting the draft into two (three) parts:
   1. fh:stateful: whether a feed is stateful or not
   2. fh:prev: state reconstruction of a stateful feed
   3. (published later) fh:????: link to archives of a non-stateful feed
(no, I actually don't want such a split, I'd rather deal with the "3."
in feed-history, no matter how)

If we want to solve this "issue" using a distinct element (fh:prev if
fh:stateful=true, fh:???? if fh:stateful=false), is fh:stateful still
needed? The presence of fh:prev would be equivalent to fh:stateful=true,
the presence of fh:???? would be equivalent to fh:stateful=false, the
absence of both fh:prev and fh:???? would be equivalent to the absence
of fh:stateful, and the presence of both fh:prev and fh:???? would be an
error.
This is off course true only if fh:prev must be accompanied by
fh:stateful=true. The question is: is it useful to have fh:stateful if
you have no link to any kind of archive?

>> I also repeat my proposal for an identifier different from an URI  
>> for a reader/aggregator to know whether it has already retrieved an  
>> archive document, e.g. using the "updated" date-time of the  
>> "fh:prev"-linked archive feed.
>>
>> Example:
>>   <?xml version="1.0" encoding="utf-8"?>
>>   <feed xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-09"
>>     xmlns:history="[TBD]">
>>     <title>Example Feed</title>
>>     <link href="http://example.org/"/>
>>     <updated>2003-12-13T18:30:02Z</updated>
>>     <author>
>>       <name>John Doe</name>
>>     </author>
>>     <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
>>     <history:stateful>true</history:stateful>
>> <!--
>> added an "updated" attribute with tha atom:updated value
>> of the http://example.org/2003/11/index.atom document.
>> -->
>>     <history:prev updated="2003-11-24T12:00:00Z">
>>       http://example.org/2003/11/index.atom</history:prev>
>>
>>     <entry>
>>       <title>Atom-Powered Robots Run Amok</title>
>>       <link href="http://example.org/2003/12/13/robots_here"/>
>>       <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
>>       <updated>2003-12-13T18:30:02Z</updated>
>>       <summary>Some text in a new, fresh entry.</summary>
>>     </entry>
>>
>>   </feed>
>>
>> If I retrieved the feed between 2003-11-24T12:00:00Z and  
>> 2003-12-13T18:30:02Z, the fh:prev URI were probably equal to http:// 
>> example.org/2003/10/index.atom (october, not november). However, I  
>> didn't miss any entry.
>> Using the fh:prev@updated value, I can know that I didn't miss any  
>> entry and that I then don't need to dereference http://example.org/ 
>> 2003/11/index.atom (november, the "new" fh:prev URI)
> 
> Hmm, that seems awfully complex (and hard to grasp -- but maybe it's  
> just me :) just to avoid a round trip.

One, or a few more... depending on how you archive your entries (daily
archive document, weekly archive document, N entries per archive
document, etc.), how you publish your entries in the subscription feed
(N entries in the feed, or only those entries published during the N
last days), and who frequently you post.
Your subscription feed entries can overlap several archive feeds and the
fh:prev jump from "archive2.atom" to "archive5.atom". Using "updated",
you can avoid 3 round trips in that case.

...or too many: what if I switch URL addressing scheme (e.g. from
"archive1.atom"..."archiveN.atom" to
"2005/January.atom"..."2005/June.atom")?
A "dumb" reader will retrieve back every archive feed, as it has never
ever dereferenced the URIs.

> That 'probably' is also worrying me.

I used probably because you didn't provide the example ;o)
Assuming that I retrieved the feed, I know the value fh:prev had at that
time.

> How would you express this in the 'reconstructing state' section?

[[
An implementation MAY store the "atom:updated" value of retrieved
archive feeds, and it MAY then stop when it encounters an fh:prev
"updated" value earlier than the latest "atom:updated" that has been
stored beforehand when following this process.
]]

-- 
Thomas Broyer

---

From: Antone Roundy <[email-masked]>
Date: Wed, 20 Jul 2005 22:05:32 -0600

> you have no link to any kind of archive?
I would think that rather than fh:stateful="true | false", it might be 
more useful to have (with a different element name, and perhaps 
different values) fh:what-kind-of-feed-is-this="sliding-window | 
snapshot | ???".  If it's a sliding-window feed, fh:prev points to the 
previous sliding window.  If it's a snapshot feed, then fh:prev points 
to the previous snapshot.  fh:what-kind-of-feed-is-this might have a 
default value of sliding-window.

---

From: "Thomas Broyer" <[email-masked]>
Date: Thu, 21 Jul 2005 12:02:12 +0200 (CEST)

Antone Roundy wrote:
>> I was actually wondering why non-stateful feeds couldn't have
>> archives: in the "This month's Top 10 records" feed, why couldn't I
>> link to "Last month's Top 10 records"?
>> If this kind of links are not dealt within feed-history, then I
>> suggest splitting the draft into two (three) parts:

+1

and with the addition of fh:prev/@updated (and an optional fh:prev/@title,
see below), it turns feed-history to a really cool extension!

We could also add some more hints about fh:prev processing depending on
fh:what-kind-of-feed-is-this:
 * if the value is "sliding-window", an Atom Processor MAY reconstruct the
feed state automatically without user interaction
 * if the value is "snapshot", an Atom Processor SHOULD NOT retrieve
archive snapshot feeds unless told by the user (e.g. showing a link or
button using fh:prev/@title as the label); when presented to the user,
entries in the retrieved snapshot feed SHOULD replace any entry from
within another snapshot (e.g. "Last Month's Top 10 records" should
replace "This Month's Top 10 records").

fh:prev/@title could be used on sliding-window feeds to indicate the title
of the latest entry in the previous feed (just like blog homepages
sometimes link to the previous entry using its title).

fh:prev would look like:
<fh:prev updated="2005-06-30T23:55:30" title="Last Month's Top 10 records"
    >http://example.net/archives/june.atom</fh:prev>

-- 
Thomas Broyer

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 23 Jul 2005 11:37:28 -0700

On 20/07/2005, at 10:44 AM, Thomas Broyer wrote:

> archives:
> suggest

My main use case for it was to advise aggregators that currently keep  
state by default (without being about to walk backwards) that this  
isn't appropriate for some feeds. E.g., NetNewsWire, Shrook and many  
other aggregators all automatically "remember" a feed's past entries  
that it's seen; sometimes, this is undesirable.

Maybe that's biting off too much at once...

>> Hmm, that seems awfully complex (and hard to grasp -- but maybe  
>> it's  just me :) just to avoid a round trip.
>

Well, if you change your archive scheme, you may change other things  
too; without more trust between the client and publisher, it probably  
*should* go back and fetch everything. This is where client-side  
throttling (as discussed before; e.g., "do you really want to go back  
that far?") would come into effect.

There are subtle issues introduced when you do time-based comparison  
across a network; synchronisation between clocks come into play, and  
it gets tricky, if not impossible, to specify correct behaviour.

Couldn't much the same effect be achieved by saying that  
implementations can use other mechanisms (e.g., updated in the  
archive itself, the id in the archive) to ascertain whether it's seen  
something before? You'd still have one extra fetch, but that's not  
nearly as big a deal as walking back the entire feed (which I agree  
would be a problem).

Cheers,

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