W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: Should CHECKOUT support a TIMEOUT?

From: John Hall <johnhall@evergo.net>
Date: Sun, 17 Jun 2001 12:33:19 -0700
To: "'Tim Ellison'" <tim@peir.com>, <ietf-dav-versioning@w3.org>
Message-ID: <000201c0f764$5d6abb40$0400a8c0@xythosjohnhall>
It seems pretty easy to add "Note: any client can issue an UNCHECKOUT".

The spec says that deleting the working resource results in an implicit
UNCHECKOUT.

But what happens to the working resource if you do an UNCHECKOUT?
Should it be deleted?

Does a WRITE-LOCK prevent an UNCHECKOUT from succeeding unless you hold
the LOCK?  That would be a round about way of adding a timeout to a
CHECKOUT request.

If a WRITE-LOCK prevents an UNCHECKOUT unless the Locks is held and
specified, then someone with a working resource could lock the VCR
first.  In that case, perhaps the VCR and the working resource should
share the lock?

I could imagine an argument to CHECKOUT that requested a WRITE-LOCK
(shared or exclusive, for those who allow multiple checkouts) that
applied to both the VCR and the working resource.  Then you would have
to deal with the issue of how to release the LOCK (on checkin, or with a
different UNLOCK command).  I sort of like that but I've got the feeling
nobody else will.

So how about adding this tidbit on the CHECKOUT command: if the VCR is
locked, the lock token must be specified for the CHECKOUT to succeed.
If the CHECKOUT results in a working resource, the LOCK associated with
the lock token specified will be applied to the working copy as well.



> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org 
> [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Tim Ellison
> Sent: Sunday, June 17, 2001 10:21 AM
> To: ietf-dav-versioning@w3.org
> Subject: RE: Should CHECKOUT support a TIMEOUT?
> 
> 
> I don't know how you could add this to the spec, since it 
> would require using language about 'client identity' that we 
> don't have.  I think this is a clear case for _not_ stating 
> something that we _don't_ do.
> 
> Tim
> 
> > -----Original Message-----
> > From: ietf-dav-versioning-request@w3.org
> > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of 
> Lisa Dusseault
> > Sent: 16 June 2001 17:24
> > To: Clemm, Geoff; ietf-dav-versioning@w3.org
> > Subject: RE: Should CHECKOUT support a TIMEOUT?
> >
> >
> > I would like to see this pointed out explicitly in the spec 
> (does not 
> > need to be normative though), rather than have the 
> behaviour left to 
> > be induced.
> >
> > lisa
> >
> > > -----Original Message-----
> > > From: ietf-dav-versioning-request@w3.org
> > > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of 
> Clemm, Geoff
> > > Sent: Thursday, June 14, 2001 2:51 PM
> > > To: ietf-dav-versioning@w3.org
> > > Subject: RE: Should CHECKOUT support a TIMEOUT?
> > >
> > >
> > > The versioning protocol places no restriction on who can
> > > do an UNCHECKOUT (if there were, you would see it specified as a 
> > > precondition for the UNCHECKOUT method).
> > >
> > > Cheers,
> > > Geoff
> > >
> > > -----Original Message-----
> > > From: John Hall [mailto:johnhall@evergo.net]
> > > Sent: Thursday, June 14, 2001 5:24 PM
> > > To: 'Clemm, Geoff'; ietf-dav-versioning@w3.org
> > > Subject: Should CHECKOUT support a TIMEOUT?
> > >
> > >
> > >
> > > ... And if not, is there a provision for someone other than the 
> > > person who did the checkout performing an UNCHECKOUT?
> > >
> > >
> >
> 
> 
Received on Sunday, 17 June 2001 15:33:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:41 GMT