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

> -----Original Message-----
> From: John Hall [mailto:johnhall@evergo.net] 
> Sent: Tuesday, July 24, 2001 8:59 AM
> To: 'Clemm, Geoff'; 'ietf-dav-versioning@w3.org'
> Subject: RE: How Clients find out if they can perform a checkout
> 
> 
> 
> 
> > -----Original Message-----
> > From: ietf-dav-versioning-request@w3.org
> > [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of 
> Clemm, Geoff
> > Sent: Monday, July 23, 2001 10:15 PM
> > To: ietf-dav-versioning@w3.org
> > Subject: RE: How Clients find out if they can perform a checkout
> > 
> > 
> >    From: Lisa Dusseault [mailto:lisa@xythos.com]
> > 
> 
> > A client has to checkout a particular version (which is the
> > version whose content defines the initial editor state of 
> > that client).  That is the version whose DAV:checkout-set and 
> > DAV:checkout-fork properties are relevant.
> > 
> > Only a PROPFIND of the version that is being checked out is 
> required.
> 
> You are assuming that a client does not need to know if ANY 
> version has been checked out, but only needs to know if THIS 
> version has been checked out.
> 
> I'm not sure that a client that does not want to deal with 
> merges can stop there, when it hits a server that allows 
> forking and multiple checkouts.
> 
> > 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.
>

Received on Wednesday, 25 July 2001 11:20:23 UTC