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:[EMAIL PROTECTED] 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
