Martin Atkins wrote:
Erik Wilde wrote:
+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?
if you find it on your disk and the feed itself tells you what
recommended update intervals are, you could set up a scheduled rsync
that would be most appropriate for the feed.
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.
actually, i should have been more precise in saying that update
properties (at least the ones i want to be able to express) are a
property of the collection (the abstract set of entries) underlying the
feed. what i want to be able to say is that there are certain
statistical properties about a collection's update properties, a little
bit like arrival processes in queuing theory. you could get even more
fancy in the context of feed queries, in which case a smart back-end
could actually tell you that while the collection as a whole updates
once every 3min on average, if you only get a filtered view of it, then
this changes to once every 30min. in that case, the update property of
the collection would change because of the "filtered view" of the
collection, as expressed in a feed query.
cheers,
dret.
