Re: Why MD5 Headers are Imperative

Eric Scheid's extended use case seems to illustrate the difference  
between the client downloading an updated resource, and the user  
noticing an updated resource.  Not quite sure if Eric S is saying  
this but it would be a reasonable position to hold that all clients  
need to be able to know when even minor changes are made, but users  
may decide only to flag for their attention non-minor changes.

On the other hand, Eric Bowman's position seems to be, if I may  
restate it, that most clients shouldn't need to know about minor  
changes.

I can't tell where most other people stand on this, but it would be  
good to be clear on the requirement before designing a mechanism.     
One could certainly design different mechanisms for each use case.

There's also a class of mechanisms that solve both use cases at the  
cost of some extra complication: let the client discover if a known  
resource's change state is major, minor or none [1].  Some clients  
will download the new resource if there are major changes and not if  
there are minor or none.  Some clients will download the new resource  
if there are major or minor changes but not if there are none.  Some  
clients may even vary their behavior depending on if they are reading  
a feed or authoring content for it.  The information is also  
available to let the user know what they want to know.

Lisa

[1] Note that this need not necessarily be a tri-state variable; it  
could be ETag for backwards-compatibility, plus some other piece of  
metadata used separately or together with the ETag.  It needs to work  
even if the client has missed a few updates: the client would have to  
be able to answer the question: compared to the version I previously  
downloaded, which might not be the latest, are there major or minor  
changes or none.


On Aug 17, 2006, at 8:28 PM, Eric Scheid wrote:

> On 18/8/06 11:36 AM, "Eric J. Bowman" 
> <eric-MkmoNbc1SAncr/OS1auqaA@xxxxxxxxxxxxxxxx> wrote:
>
> > then you are making an end-run
> > around giving the publisher control over what constitutes a  
> > significant
> > update by forcing all those insignificant changes to be exposed  
> > for all
> > consumers of the document.
>
> If the publisher doesn't want the "insignificant" changes published  
> to the
> world, then they just simply shouldn't publish it.
>
> On the other hand, the atom:updated element, including the  
> "significant
> change" bit, was deliberately set up to allow this kind of example:
>
> 10.00am: author POSTs a new entry
>             it gets published
>
> 10.01am: subscribers retrieve the entry,
>             emails and comments fly
>
> 10.30am: author PUTs an edited version,
>             containing "this just in: I got it wrong!"
>             with atom:updated = 10.30am
>
> 10.31am: any subscribers who previously retrieved the entry
>             can now be alerted to the fact that there is a
>             significant change to the content
>
> 10.32am: any subscribers who hadn't as yet retrieved the entry
>             still get the updated version, and they read it as new
>             because to them it is new
>
> 11.00am: author is alerted to some trivial spelling errors,
>             is already feeling bone headed
>             prefers to avoid having even more comments regarding  
> errors
>             author PUTs an edited version
>             with atom:updated = 10.30am
>
> 11.01am: any subscriber who had previously retrieved and read the
>             entry may retrieve this version, but it hasn't been
>             marked as being changed to the extent it should be brought
>             to their attention, but if they were to go read it again
>             then they would see it sans spelling errors
>
> 11.02am: any subscriber who retrieves it for the first time
>             gets to read the original content, the update, and
>             would never guess there were spelling corrections applied
>
> That is, if it's important enough to warrant fixing, then it should  
> appear
> to anyone requesting that resource. That doesn't however  
> necessarily raise
> it to the level of importance that warrants a re-read by subscribers.
>
> If however, for whatever reason, my boss wanted to institute a rule  
> that
> only significant edits get published, then the publishing CMS would  
> store
> the 11.00am version but only present the 10.30am version. Or it might
> respond to the 11.00am PUT with some 5xx response saying "get  
> serious, stop
> bothering the poor overworked CMS with minor edits, you made a  
> boob, live
> with it". I don't know what 5xx code that might be ;-)
>
> e.