James Holderness wrote:
Thomas Broyer wrote:
You didn't answer my last question:
How do you expect a newsreader to *automatically* download this
week's 50 entries without downloading last week's entries instead?
(and show you links/buttons for you to ask download and display of
previous/next week's Top 50)
I see where you're coming from, but this kind of thing is already a
problem without even taking links into consideration.
For an aggregator to be able to do anything vaguely meaningful with a
feed it has to be able to assume that the feed is incremental in nature.
As I already explained, paging is orthogonal to the incremental nature
of a feed. An incremental feed will be chunked as explained in Mark's
current Feed History draft (just use an atom:[EMAIL PROTECTED]"previous"]
instead of the fh:prev extension element) and a non-incremental feed as
described in the OpenSearch result 1.1 draft. The difference is that an
incremental feed is sorted by date so the older parts will become more
or less "stable" over time; while a non-incremental feed is replaced as
a whole each time it is updated, with no other relation to time.
When the feed is updated an aggregator will by default assume that any
new items can safely be added to the top of an inbox, any updates are
updates to existing items, and any removed items have merely "fallen
off the bottom" of the feed.
However, as soon as we introduce the concept of non-incremental feeds,
an aggregator that is not aware of the concept will fail to process
such a feed in a meaningful way. We've created a situation where an
aggregator has to be aware of the (still to be specified)
fh:incremental extension, Microsoft's simple list extensions for RSS,
and whatever future extensions may arise; basically the ability to see
into the future.
This problem merely repeats itself when it comes to processing
archives. When we receive a "next" link, ideally we would like to
assume it's a pointer to the next archive to be processed. For a
regular incremental feed this isn't a problem. Even a search feed
could be processed safely if ordered the right way. However, when it
comes to non-incremental feeds we're screwed again. I agree that it
sucks, but we're already stuck with that situation so I'm not sure
that these links will make things any worse.
What's the difference between a search feed and a non-incremental feed?
Aren't search feeds one facet of non-incremental feeds?
The difference between incremental and non-incremental feeds is that,
when dealing with incremental feeds, paging can be seen as a link to
archives, as the feed is tightly related to time. When dealing with
non-incremental feed, the "previous page" is totally different than the
"previous archived snapshot".
However, an incremental feed could take advantage of differentiating
between paging and "archive linking": if linking to archives uses an
atom:[EMAIL PROTECTED]"archives"] (or call it "history" if you prefer) to point
at an incremental feed where each entry describes an archived set of
entries (see [1] for a more detailed example); such a feed has the
advantage of paging that it allows direct access to a specific point of
time inside the feed "pages". Each "archived set of entries" could for
example cover one or two week, so a user could navigate through the
"feed state" or "feed history" not only by going from pages to pages but
also by accessing archived chunks via an "index" or "table of contents".
--
Thomas Broyer
