RE: Summary of ETag related issues in RFC2518bis

"Dan Brotsky" <dbrotsky@adobe.com> wrote on 12/21/2005 01:22:17 AM:

>> I think a WebDAV client cares about both optimistic locking 
>> and caching. 
> 
> I strongly disagree.

Like Lisa, our client writers care about both optimistic locking
and caching.  And I don't think we are the only ones that feel that way.

>>  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.

Our client writers care about all three, i.e. optimistic locking (whose
definition we appear to agree on), GET caching (i.e., what you define as
caching), and re-use of the content submitted for a PUT (included in my
more general definition of caching).

> 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.

I am happy to use "caching" to only mean "GET caching"
if that's what you prefer, but our clients also care about the more 
general
form of caching that I described, whatever name we use for it.
One of the points of this discussion is to determine whether clients 
should
be able to use etags returned by PUT for this other kind of 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.

Our WebDAV clients also care about performance, so they also care about
caching, not just about optimistic locking.

Cheers,
Geoff