On 20 Feb 2005, at 7:38 pm, Bob Wyman wrote:
would still be known. Note the originating server doesn't have to store or keep track of anything.
You propose timestamps, yet you oppose atom:modified -- which was
intended to provide precisely the timestamps you suggest. Or, is there
something I am missing? (atom:modified was entry-specific but you seem to be
suggesting a feed-global timestamp...)
No. As I said earlier, the only property of atom:modified we're interested in is:
date(a)<date(b) whenever entry instance a is older than entry instance b"
Let's define an atom:version date element for each entry that has only that constraint. You can obviously still use a Last Modified Date to fulfil it. But what you can also do is have the originating server stamp each entry with the current date and time, and it still works. For example, if a client receives an old cached version, it will have an older date and can be discarded if an entry with a newer atom:version date is already known.
Does your timestamp proposal imply that an entry which appeared in
multiple feeds would have a different timestamp in each feed it appeared?
Yes.
(Note: That would have the odd effect of tending to make error-prone copies
consistently appear to be the 'last modifications.' One tends to write to
the "main" feed first and then later to "category" feeds... Copies will
generally have timestamps later than the originals.)
We're talking serving static files, right? In this case the category feeds would still contain the old date they were generated until they were updated, preventing them from overwriting newer versions.
Graham
