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

I agree with Stefan. I see little to be gained distinguishing between the
Allow header and DAV:supported-method-set. In any case, clients must use
the information obtained from the server cautiously as the state may change
from one request to the next. That is, a client can use information from
the server to adjust its UI in order to indicate available functionality to
its users, but it should be prepared to be wrong and recover gracefully. On
the web, you find out what you can do by trying and seeing.



                                                                                                                        
                    "Stefan Eissing"                                                                                    
                    <stefan.eissing@greenbyt       To:     <ietf-dav-versioning@w3.org>                                 
                    es.de>                         cc:                                                                  
                    Sent by:                       Subject:     RE: How Clients find out if they can perform a checkout 
                    ietf-dav-versioning-requ                                                                            
                    est@w3.org                                                                                          
                                                                                                                        
                                                                                                                        
                    08/03/2001 05:12 AM                                                                                 
                                                                                                                        
                                                                                                                        



> [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 Monday, 6 August 2001 15:12:47 UTC