On Wednesday, June 29, 2005, at 06:50 PM, A. Pagaltzis wrote:
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
For an active feed, that document could easily grow till it was larger
than many feed instances. I prefer the chain of instances method.
, 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/
I don't quite get what the "hub feed" would look like. Could you show
us some XML?
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.
The draft doesn't explicitly say that a feed can only contain one
"prev" link, but I find it hard to read "a" to mean "one or more" in
'and optionally a Link element with the relation "prev"'.
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.
...unless they expected only to find one "prev" link per document.
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).
I don't see why this would be any more difficult. The paginated
approach could easily use static documents that never need to be
updated, as I described earlier. I'll re-explain at the end of this
email.
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
Could you explain what you mean by that?
I’d much rather have a single archive feed containing all
entries, and use RFC3229+feed to return partial versions of it;
That might be good for those who can support it, but many people won't
be able to. On the other hand, if that single feed grows to where it's
hundreds of MB, it could cause real problems if someone requests the
whole thing or a large portion of it.
Getting back to how to use static documents for a chain of instances,
that could easily be done as follows. The following assumes that the
current feed document and the archive documents will each contain 15
entries.
The first 15 instances of the feed document do not contain a "prev"
link (assuming one entry is added each time).
When the 16th entry is added, a static document is created containing
the first 15 entries, and a "prev" link pointing to it is added to the
current feed document. This link remains unchanged until the 31st entry
is added.
When the 31st entry is added, another static document is created
containing the 16th through 30th entries. It has a prev link pointing
to the first static document. The current feed document's prev link is
updated to point to the second static document, and it continues to
point to the second static document until the 46th entry is added.
When the 46th entry is added, a third static document is created
containing the 31st through 45th entries, etc.
If you want to reduce the number of requests required to get the entire
history (which I don't imagine would happen often enough that it would
necessary be worth bothering), you could put more entries into each
static document. If you didn't correspondingly increase the number of
entries in the current feed document, you'd have to update the most
recent static document a number of times rather than only outputting it
once as described above, but even that would only require multiple
updates to the most recent static document at any time.
