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

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 
28. You were the one who pointed out that solving the problem we were 
discussing required strong ETags, not weak ETags.

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

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

Lisa

Received on Tuesday, 29 November 2005 21:29:08 UTC