RE: Last Call for DAV:checked-out-vcr Proposal

Consider this a stand up, hand over heart, this is a vital use case for
them (me) statement.

Note that my use case is different from the one Geoff stated.  I don't
want to support UPDATE or MERGE.  Just CHECKOUT (the VCR to a working
copy) and CHECKIN (working copy to update the VCR).  

That is how I wish to build my server, and it tracks the semantics of
the 3rd party non-DeltaV versioning server I want to be compatible with.

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org 
> [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Tim Ellison
> Sent: Tuesday, June 19, 2001 7:01 AM
> To: DeltaV (E-mail)
> Subject: Re: Last Call for DAV:checked-out-vcr Proposal
> 
> 
> "Clemm, Geoff" <gclemm@rational.com> wrote:
> > The DAV:checked-out-vcr property addresses the use case
> > where a working resource has been created for the purpose
> > of updating a VCR, and then that VCR has been moved while
> > the working resource was checked-out.  Since the client 
> cannot easily 
> > track the movement of the VCR, the DAV:checked-out-vcr property 
> > provides functionality that cannot be achieved by the 
> current protocol 
> > for the client-workspace package
> 
> I would like to see someone stand up, with their hand on 
> their heart, and say that this is an important use case for 
> them.  I'm increasing resistant to adding new functionality 
> to DeltaV unless we have these 'compelling' cases.
> 
> Is it really the case that clients would not wish to recover 
> from this situation should it occur rarely, or lock the 
> version-controlled resource should it occur frequently?
> 
> Skeptically yours,
> Tim
> 
>

Received on Tuesday, 19 June 2001 12:04:10 UTC