Tim Bray wrote:
> As a matter of policy, my feed contains the most recent 20
> posts. However, if one of those posts is a long post and only the
> summary is provided, when I make a change, I make a conscious
> decision whether it's sufficient that I want newsreaders to re-fetch
> it, and if so I change the datestamp, otherwise not.
Finally, your true motivations appear. It is now clear that you're
not talking about Atom itself. Rather, you are trying to regulate the
behavior of Atom Processors who will be using Atom feeds somewhat like
"ping" feeds that tell them which entries to fetch. Your concerns are easily
addressed by providing text in the specification that makes clear what you
want.
I therefore propose the following text:
To the discussion of both atom:updated and atom:modified add:
"[Non-Normative: In order to preserve network bandwidth and reduce the load
on hosts of resources linked to Atom feeds or entries, Atom Processors which
fetch the contents of alternate links are advised that they should not
re-fetch such contents unless atom:updated changes.]"
To the discussion of atom:modified add this normative text:
"The value of atom:modified MUST only be changed when some other element
(including atom:updated) of the same Atom entry has changed. Changes which
are limited to resources linked to the Atom Entry MUST NOT trigger changes
to atom:modified."
> Since I'm a good citizen about specs, I would do this wasteful thing.
If the spec were written as I have proposed above, then you -- as a
"good citizen" -- would never re-fetch the alternate linked resources unless
atom:updated changed.
The difference here is that my comments have been solely focused on
the contents of the Atom feed -- which is all that PubSub is concerned with.
Nonetheless, the proposed texts should resolve your issues while allowing
PubSub to do its job.
bob wyman
