Graham wrote:
> My idea would be that the originating server would simply stamp
> entries with the current time during feed generation, so if they
> get mixed up in transit by third parties or caches the later version
> 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...)
Is the problem in your comment that "the originating server doesn't
have to store or keep track of anything"? Does this imply that your
timestamp is really just the atom:updated of the feed and would change every
time that the feed was updated? If this is the case, should we reword the
definition of atom:updated to say that when it is used as feed metadata, it
MUST be updated every time the feed is changed in ANY way? Should the
"significant change" words only apply to atom:updated in entries? (Note:
Since the feed's atom:updated is an element of Head, this implies that if
HeadInEntry stands, the feed's atom:updated would or could be "in the
entry.")
If your timestamp is really the same as the feed's atom:updated,
then what is the impact of your proposal on signatures? Would all individual
entries in a feed need to be re-signed every time any change was made to the
feed such as inserting a new entry? Would this be the case even if the
change did not otherwise modify the signed entry?
Does your timestamp proposal imply that an entry which appeared in
multiple feeds would have a different timestamp in each feed it appeared?
(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.)
> Generating a last modification date according to someone else's
> idea of modification is not pretty.
Yes! This is the problem that an intermediary in the channel faces.
The intermediary (a proxy, retrospective search engine, prospective matching
engine, etc.) needs to know which entry is the most recent modification.
However, Atom provides no mechanism by which the last modification can be
identified without heuristics. (atom:updated only tells you the time of the
last "significant" modification but that leaves you unable to determine
which of various alternative "insignificant" modifications should be passed
on by the intermediary.
Without help from the Atom format, the best an intermediary can do
is keep track of "date_entry_was_found". However, this can cause problems
since entries can exist in multiple feeds. Thus, the order in which the
feeds are read can cause old entries to over-write newer ones.
bob wyman
