Re: Summary of ETag related issues in RFC2518bis

Hey Dan, I'm a client developer now and Chandler definitely cares about 
both optimistic locking and caching :)  We want to be able to share 
collections of arbitrary files between users, but those collections 
should also be accessible offline.  The client can be responsible for 
merging content in case there's already a change to a cached resource 
changed while offline.

Lisa

On Dec 20, 2005, at 10:22 PM, Dan Brotsky wrote:

> > The last part is important for a WebDAV client, since it wants to use
> > ETAG for optimistic  locking. It is not really interested in ETAG for
> > caching purposes.
>
> Actually, I think a WebDAV client cares about both optimistic locking
> and caching.   
>  
> I strongly disagree.  I think the first author's statement is correct.
>  
>  Also note that they are rather intimately linked, since
> optimistic locking is based on knowing that the client's edits are 
> based on the
> text that is currently on the server, while caching is based on knowing
> that what the client currently has is based on the text that is 
> currently on
> the server.  
>  
> No.  Optimistic locking is based on knowing that the client's edits 
> are being applied to the content the client last sent to the server, 
> and are not overwriting other client's edits.  Caching is based on 
> knowing that the content you *last received* is the same as what you 
> *would receive* on your next get.
>  
> HTTP clients, whether webdav or not, know they must have *received* 
> the content associated with an etag in order to avoid fetching it 
> again.  That's caching.
>  
> WebDAV clients only need to know that they *sent* the content 
> associated with an etag in order to avoid overwriting someone else's 
> edits.  That's optimistic locking.
>  
>     dan
>