RE: How Clients find out if they can perform a checkout

> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> 
> > From: John Hall [mailto:johnhall@evergo.net] 
> > 
> > > From: Clemm, Geoff
> > 
> [...]
> > > Using just
> > > DAV:supported-method-set and the Allow header is much simpler 
> > > and sufficiently accurate.
> > > 
> > > It's deliberately vague to give the server some leeway, but
> > > in general "supported" means that the method might succeed on 
> > > some state of the resource, while the Allow set indicates 
> > > whether the method might succeed on the current state of the 
> > > resource. I agree this is worth stating in the protocol (if 
> > > people agree with this characterization).
> > 
> > I think it is worth stating.
> 
> Yup, but we first have to get Stefan to agree (:-).

Let's see what the "most bang for less bugs" principle can do 
for this discussion:

A client cannot retrieve the Allow header and the DAV:supported-method-set
at the same time. It's always two (most likely three) requests. Depending 
on the usage, not the implementation of the server, the two method sets
 reflect the same state of the resource - or not (I am talking about 
unlocked resources here since clients should not need to lock, just to 
find out what they can do with it).

So, all your client knows after retrieving the two sets, is that at that
point in time it was:
a) possible right now to perform a checkout - or not (from Allow header),
b) generally supported to checkout - or not (from supported-method-set)

My point is that a) is useless in a client-server protocol, and that
b) is very useful. If CHECKOUT is supported, you only _know_ that
it succeeds when you try it out. 

I propose to give the Allow set and the DAV:supported-method-set
the same definition, namely, that they include those methods which
may succeed on some state of the resource (e.g. the current definition
of DAV:supported-method-set), at least for all WebDAV extension methods.

What can be gained by this?
1. Consistency and performance: it is possible to retrieve a consistent
   view of what there is to know about a resource with one PROPFIND, with
   varying depth even for a range of resources.
2. Simpler implementations on server side. Servers do not
   need to implement two sets of methods with one varying on every state
   change.
3. Easier (if that's possible) understanding of the deltaV spec, e.g.
   one feature less.

Point 1. is my wholy grail. It makes clients faster and keeps them
simple. A client does one, single PROPFIND depth 1. Either it fails,
with error to user, or it has the complete information about a
collection and all of its members. This is very powerful use of
WebDAV + XML. Try that with RPC or SOAP.

//Stefan

PS. Before someone asks: I think my definition does comply with Allow 
as described in RFC 2616. There is never a NOT IMPLEMENTED returned 
by a deltaV server on a method from DAV:supported-method-set.

Received on Friday, 3 August 2001 05:13:00 UTC