+1 to everything Eric said below.
We're not in the same context; we're not talking about atom:modified but app:modified. Moreover, as Atom-Protocol enforces Member Resources to have their own URI (in the general pub/sub scenario, Atom Entries are only available as parts of Atom Feeds), app:modified is "verifiable" against the Last-Modified HTTP header. Eric Scheid wrote: > > On 9/11/05 4:14 PM, "Tim Bray" <[EMAIL PROTECTED]> wrote: > >> 1. Either you trust the party on the other end of the protocol or not. > > That's describes well the situation of a publisher at one end, and a > consumer at the other. With Atom Publishing Protocol, both parties are > (generally) the one person -- the author of the entry. > > This means the issue at hand isn't one of trust. > >> 2. If you trust the party, then you are probably prepared to agree >> that an update that party doesn't think is significant, is >> insignificant. > > Define the context for significant. What I as author consider important > enough to bother modifying the entry may not be important enough to tell > my > audience is a significant update to the entry. > >> 3. If you don't trust the party, then you know perfectly well that >> they might lie about atom:modified, so you'll fetch the data and >> check for changes anyhow. > > Sadly, I'm still able to tell when I lie to myself. What I don't want is a > server that lies to me -- if I know I've changed something, then I don't > want the server to say 'nothings changed'. > >> 4. If you have an atom:modified that is required to be updated on >> every change no matter how insignificant, you have opened the doors >> to endless arguments as to what constitutes a change: adjusting white >> space between attribute values? Changing the stylesheet? Either you >> trust the publisher's judgment or you don't. > > Defining what "modified" means in the context of Atom Syndication Format > certainly has all those rat-holes you mention, but in the context of Atom > Publishing Protocol it's a lot simpler .. if the entry is PUT, it's > modified. That's an objective measure. > > My file system doesn't bother checking the references in my footnotes in > my > word processing documents to figure out if the Yuan exchange rate has > shifted causing a shift in the egg commodity market. It doesn't even > bother > comparing the blob that was with the blob that is PUT. If my application > executes a save to disk, then the file's modification data is nudged. > > I'm quite happy to have my web browser rely on HTTP Last-Modified headers. > I > don't require my web-browser to calculate hashes of the http response > bodies. Caches rely on Last-Modified headers, they (AFAIK) don't calculate > hashes. We're not going to legislate in APP that HTTP If-Modified-Since is > outlawed or is inherently inreliable, are we? > >> Thus, trying to write a dependency on a date-you-trust-a-publisher-to- >> provide-even-if-the-publisher-thinks-it's-not-significant into the >> protocol is a waste of time. > > Multiple Personality Disorder and paranoia are not something we need to > worry about, is it? -- Thomas Broyer
