One way to look at this is to define what parts are local content
as opposed to caches of remote, and base the Etag or other hash on
that.
I still think we should address caching in Atom 1.0. This would
have been part of that. Scaling is an essential thing for syndication,
and caching is the best
On 7 Apr 2005, at 7:48 pm, Bob Wyman wrote:
Of course, the side effect of this change is that any aggregator
that uses an MD5-like approach to detect changes will now think that an
entry has been updated every time a new comment is made. This may or
may not
be what is desired by consumers of
Graham wrote:
On 7 Apr 2005, at 7:48 pm, Bob Wyman wrote:
Of course, the side effect of this change is that any aggregator
that uses an MD5-like approach to detect changes will now think that an
entry has been updated every time a new comment is made. This may or
may not
be what is desired by
Graham wrote:
I don't seriously believe any aggregator that uses the content hash
approach would survive very long in the market place without being
buried under user complaints. Most (the one's I know of) either use
identifiers or failing that some subset of the elements.
The
* A. Pagaltzis [EMAIL PROTECTED] [2005-04-07 22:55]:
F.ex, entries maliciously published with someone elses entry
ID will not actually constitute a DOS attack for consumers
whose aggregator maintains a history of previously seen
versions of an entry.
Sorry, wrong thread. I have been
On 8/4/05 6:49 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
I don¹t believe we can forsee
all of these, so let¹s not try to. The Atom format should specify
hooks (such as the atom:source subelement Thomas suggested,
possibly?) which would allow trust models or other coping
mechanisms to be
