Hi Mark,
* Mark Nottingham <[EMAIL PROTECTED]> [2005-06-28 22:40]:
> This document specifies mechanisms that allow feed
> publishers to give hints about the nature of the feed's
> statefulness, and a means of retrieving ^missed^ entries
> from a stateful feed.
I agree with Antone Roundy that the “this” link is unncessary
for the reasons already stated.
My first thought upon reading the draft was what I assume is
what Stefan Eissing said: I would rather have a single,
entry-less “archive hub” feed which contains “prev” links to
*all* previous instances, leading to a setup like
http://example.com/latest
└─> http://example.com/archive/feed/
├─> http://example.com/archive/feed/2005/05/
├─> http://example.com/archive/feed/2005/04/
├─> http://example.com/archive/feed/2005/03/
├─> http://example.com/archive/feed/2005/02/
└─> http://example.com/archive/feed/2005/01/
so that it’s only necessary for the aggregator to fetch one
document to find out about all previous versions. It seems
cleaner and more robust to keep a global history list, rather
than encoding it implicitly as a chain of documents.
I don’t see anything in the draft that would preclude this use,
and as far as I can tell, aggregators which support the draft
should have no trouble handling this scenario correctly. Is it
acceptable, or did you intend to outlaw it? If yes, what is the
reasoning?
In fact, I’d probably go one step further and add a “prev”
link to each version, which points back to the archive list
feed.
http://example.com/latest
└─> http://example.com/archive/feed/ <────────────┐
├─> http://example.com/archive/feed/2005/05/ ─┤
├─> http://example.com/archive/feed/2005/04/ ─┤
├─> http://example.com/archive/feed/2005/03/ ─┤
├─> http://example.com/archive/feed/2005/02/ ─┤
└─> http://example.com/archive/feed/2005/01/ ─┘
In that way, any of the files can be copied around the place,
but they never lose their association with the originals.
Again, I don’t see anything in the draft that would preclude
this use, and as far as I can tell, aggregators which support
the draft should have no trouble handling this scenario
correctly. Is it acceptable, or did you intend to outlaw it? If
yes, what is the reasoning?
Note how the archive directory feed being static makes this
painlessly possible, while it would be a pain to achive
something similar using the paginated approach with local
“prev” links (you’d need to go back and change the previously
newest old version every time a new one was added). It would
in fact require a “prev” link to what is actually the “next”
page.
Funnily enough, I don’t see anything in the draft that would
preclude this counterintuitive use of the “prev” link to point
to the “next” version, and as far as I can tell, aggregators
which support the draft [etc]?
Overall, I must say this feels kludgy to me, any way I turn it.
I’d much rather have a single archive feed containing all
entries, and use RFC3229+feed to return partial versions of it;
as far as I can tell, this is a use case which your draft does
*NOT* allow. Is that so?
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
