Erik Wilde wrote:
Stephane Bortzmeyer wrote:
On Mon, Jul 06, 2009 at 12:41:32PM +0100,
James Abley <[email protected]> wrote
HTTP already provides Cache-Control: / Expires: to indicate how long
a client may like to wait before checking if the representation has
been updated. Would that meet your requirement?
IMHO (I'm not the OP), no. Feed producers (who know the duration of
the feed) may not have a way to set HTTP headers. Also, HTTP headers
are not end-to-end, they are lost if, for instance, the feed is
transferred by non-HTTP means (such as rsync or scp). I would prefer a
solution inside the feed.
+1. the update properties of a feed are a property of the feed, not of
the protocol. these things are related, but keeping the properties as
part of the feed format would make a feed document more self-contained,
would allow feed publication in scenarios where HTTP headers cannot be
easily set, and might also allow more sophisticated/specialized
properties than HTTP's cache control.
If you rsync a feed from one host to another, does that guarantee that
the new copy will be updated with the same frequency as the original? To
pick another example, if I download a feed and put it on the hard drive
of my laptop here, will it continue to update at the same frequency?
With these examples in mind, I'd argue it's actually wrong to put it in
the feed itself, since the update frequency is a property of a
particular published instance of a feed, not an "end-to-end" property
that is preserved when you duplicate the feed elsewhere.
Of course, it may be useful to know where the "original" instance of a
feed came from, which is why it makes sense to have link rel="self" in
the feed rather than in the headers: that property doesn't change as
copies are made by definition.
