Re: PaceFeedState

["Bill Kearney" <wkearney@xxxxxxxxxxx>]

> There is nothing in the proposal that requires sites to make all
> entries available, nor is there anything that requires clients to
> download them all.

FUD aside, there is something to be said for clearing up the confusion about
what's a feed and how tools are expected to use as well as NOT use them.

That a source has a 'current items' docuemt that models RSS is what I think
most people are going to consider a "feed".  That it might contain
indicators on how to retrieve a "previous" instance of itself and/or a range
of additional (if not all) entries seems to be what you're proposing.  The
"prev" examples seem like reasonable ideas.  How a tool should "walk" itself
back over them it certainly something worth establishing some clear
practices on doing.  As in, let's avoid the insanity of feeds without
timestamps and the like.  Let something that has the 'current' feed detect
and retrieve the 'prev' document and perhaps use timestamps to assure that
it is or isn't 'later' that what is known locally.

As an aside, I can see real headaches for many current feed handling tools
in dealing with previous quantities of items.  They'll need to change and it
may not be pleasant for them.  That said, for a reader to be able to walk
back through the entries would be a very good feature.  Should a site want
to provide it, that is.

As to how a consumer of a feed should branch out an use some larger set of
if not all, entries is something worth discussing.  The idea of some
half-baked feed tool mercilessly polling a wholefeed URI every hour, on the
hour, is a nightmare we'd really do well to avoid.

-Bill Kearney
Syndic8.com