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

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

From: John Hall <johnhall@evergo.net>
Date: Tue, 19 Jun 2001 09:04:09 -0700
To: "'Tim Ellison'" <Tim_Ellison@uk.ibm.com>, "'DeltaV \(E-mail\)'" <ietf-dav-versioning@w3.org>
Message-ID: <000101c0f8d9$79cf14e0$0400a8c0@xythosjohnhall>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC