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

Lisa Dusseault wrote:
> On Nov 29, 2005, at 12:07 PM, Julian Reschke wrote:
> 
>>
>> It seems that you have a very specific authoring scenario in mind, 
>> which you'd like to be simpler to support in a client. How about 
>> summarizing the *precise* requirements first, then think about the 
>> right technical approach, and only then discuss a way what to do in 
>> the spec? Yes, that's more work to do then simply stating "Strong 
>> ETags are now required", but it's the better approach nevertheless.
>>
>>
> 
> First, before discussing the precise requirements I have in mind, I'd 
> like to remind you that the "Strong ETags" proposal didn't come from me 
> alone, I'm not the only one with requirements.  After the 2002 interop 
> where this was first discussed, we had a bunch of list discussion about 
> this in late 2002, e.g. Dan Brotsky's email of Oct 16 and yours of Nov 

I guess it would be good if people would just re-read what was discussed 
back then (Dan: 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0119.html>, 
myself replying: 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0141.html>).

If there was consensus back then, it was for:

1) ETags are good. Strong ETags are better. Optimally, PUT returns a 
strong Etag.

2) Server support for ETags must be consistent (that is, DAV:getetag and 
ETag response header should agree)

Re 1) I don't think there's any disagreement here. The question is how 
to achieve it. Putting SHOULD- or MUST-level requirements into the spec 
without understanding why servers may not be doing it already is IMHO 
the wrong approach.

Re 2) Of course. If that needs clarification in the spec, let's do it.

> 28. You were the one who pointed out that solving the problem we were 
> discussing required strong ETags, not weak ETags.

What I pointed out was that the requirement you want to make makes 
Apache/mod_dav non-compliant, as it returns weak ETags upon PUT.

> The requirements:
>  - 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.

Yes. It's good when this is the case. On the other hand, it's also good 
when servers can support WebDAV for a wide range of resource types, not 
just filesystem-like stores.

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

ETags do that. If a server doesn't support ETags, the client always can 
refuse to update.

On the other hand, as Wilfredo just pointed out, filesystems do not have 
ETags either, and people just live with that (last update wins). So yes, 
it's nice if you can avoid it, but it's unclear why it needs to be a 
WebDAV requirement.

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

So are you now requiring that a WebDAV server can store any type of 
binary content? What if it's a WebDAV connector on top of an XML database?

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

It's hard to judge what that actually means protocol-wise.

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

As far as I can tell, the recent discussion on the HTTP mailing list 
shows that ETags do not help with that.

> I generated these rather off-the-cuff, but I believe that's a good start 
> at least.

Best regards, Julian

Received on Wednesday, 30 November 2005 10:54:37 UTC