RE: error condition for delete of VHR when VCR is in checked-in c ollection

> From: [email protected]
> [mailto:[email protected]]On Behalf Of Tim Ellison
> Sent: Tuesday, July 09, 2002 10:39 PM
> To: [email protected]
> Subject: RE: error condition for delete of VHR when VCR is in checked-in
> c ollection
>
>
>
> > I think we need to distinguish between
> >
> > a) references to version histories / versions that are correct,
> > but specific
> > users may not dereference/GET them (I don't have any problem with
> > that), and
>
> Agreed.
>
> > b) references that are dead (because the resource they point to
> is gone).
> >
> > In case b), there's no way a subsequent CHECKIN or CHECKOUT can satisfy
> > RFC3253's postconditions, so I'd consider this a broken state. There
> > shouldn't be a protocol-tolerated way to get into this state, right?
>
> Agreed.  ...and there is no way in HTTP to ensure that a resource is gone,
> so we are cool, right?

I don't understand this one. So...

- DAV:href references to versions may be broken -- for instance because the
versioning server is only loosely coupled, and the versions actually live in
a different system. That the references point to non-accessible/gone
resources isn't really a problem during checking in / checking out -- but
for instance UNCHECKOUT or UPDATE may fail later.

- My point is that this is an error condition. Yes, it may happen. But, I
think it is wrong that a client can get into this state by just doing
RFC3253-allowed requests. At the very least, the DELETE sematics for VHRs
should *warn* programmers that the side effects of the deletion of a VHR may
be surprising :-)