Re: ETags, next call, was: Notes on call from today ...

   OK, this is a good list.

On Nov 29, 2005, at 1:28 PM, Lisa Dusseault wrote:

>  - Clients must be able to interoperate against different server  
> implementations with great consistency.  That means that there  
> should be very few cases where clients need to determine what the  
> server implementation is or what features it supports, or how,  
> before choosing between alternative code paths.

   Semantic equivalence requires an agreement on the meaningful  
features of a resource's content, and presumably not any knowledge of  
the server.  It is of come concern, though, that the former is  
difficult (all servers and clients need to agree on equivalence) and  
that difficultly may cause the latter.

>  - Clients must be able to be confident, when doing a PUT, that  
> they are not overwriting another client's change -- that means that  
> there must be some way to compare the state of the resource to the  
> state when it was last retrieved.

   Weak ETags should be sufficient here, though the behavior might be  
different.  Weak ETags imply that the server knows something about  
semantic equivalence, and the server is telling you that the document  
hasn't meaningfully changed.  If overwriting the other client's  
change is bad, that's presumably because the other client's change  
was meaningful.  So the problem remains in defining what's a  
meaningful change in the context of that resource.

>  - Specifically, this must work for images, HTML pages, office  
> documents, etc -- without requiring any different behavior on the  
> part of a client.  It would be nice if the server didn't have to  
> care what kind of resource it had, as well.

   Right, and we're OK with how it works with strong etags.  With  
weak etags, if the server knows nothing about the semantics of the  
resource, it shouldn't be issuing a weak etag to you (because that  
would imply that it does know).  If the server does send you a weak  
etag, you know that the server thinks they are equivalent.  Again,  
this means you have to trust the server to actually know.  Clients  
don't generate etags, so the reverse isn't required.

>  - It must be possible to write a generic library or remote file  
> system, such as WebDAV FS, Xythos WFC or Adobe's library -- one  
> which communicates with the WebDAV server on behalf of an  
> application such as Word or Photoshop, without requiring overly  
> heavy integration between the application and the library.

   In filesystems, the last writer simply wins, and stomping another  
client's change is OK.  Some apps do check if a file changed before  
saving, and they typically use last-modified timestamps for that; I  
don't know any filesystems with an equivalent to ETag.  Perhaps  
that's a bad example.

   But the prior counterpoint stands.  The server is the arbitrator  
here.  If the server says the document didn't meaningfully change,  
then the client should be able to rely on that.

   What I think we need is an example scenario where I GET a  
document, the weak etag didn't change, so I PUT it back on save, but  
in the mean time the document change in a manner that the server  
deemed semantically equivalent, and that's somehow a problem for me.

>  - Clients must be able to keep an offline store with content  
> that's fairly reliably consistent with what's on the server.  (One  
> problem to solve here is for the client to know whether it needs to  
> download a resource after a PUT)

   Same argument.  Server tells you it hasn't changed in a way that  
you care about.

   It may have changed in a way that you don't care about.  Assuming  
it did, why do you need to update your local copy, given that you  
don't care?

   That is, what's a scenario in which the semantics did not change,  
but the client needs to reload the document anyway or should refuse/ 
hesitate to do a PUT?

	-wsv

Received on Tuesday, 29 November 2005 22:17:40 UTC