Re: Re (2): Removing a resource: A compromise that satisfies?

Edgar@EdgarSchwarz.de wrote:
> Tim_Ellison@uk.ibm.com wrote:
> > ..and there was a flood of messages to the list.
> > After following the arguments (any my blood pressure rising and
> > falling numerous times)
> Me too :-).
> My understanding is that a versioning unaware client should NEVER
> have the side effect of deleting version resources it doesn't know
> about. The server side concerns Lisa raises are another matter I don't
> have the time to discuss at the moment.

I also find it surprising that people would want that.  But Geoff has
cleverly worded the postcondition so that only 'branches' of version
history can be deleted upon a version-controlled resource deletion until
the final version-controlled resource departs, the postcondition is
optional ("MAY"), and the clearly misguided version deletion behavior <g>
is forbidden for those servers that implement version history.

> Now to Geoffs proposal.
> Clemm, Geoff wrote:
> > How about an alternative approach:
> >
> > Add a new postcondition to DELETE that says:
> >
> > "If a server does not support the version-history feature,
> > then it MAY automatically delete a version resource if that
> > version no longer appears in the DAV:version-tree report
> > of any version-controlled resource."
> Here you draw a fine line between explicitly having a version
> history ('support the version-history feature') or implicitly
> having it ('appears in the DAV:version-tree report') because
> the version tree is the fundamental data of a version history.
> Or isn't it ?
> To me it seems that VERSION-CONTROL is providing a version-history
> light in the form of the version-tree report. Does that make sense ?

Sure, even where the version history resource does not exist, the versions
still do so.  That is why I'm a bit surprised that people won't implement
version history since the overhead is only a few simple live properties
exposing data that will be maintained anyway -- it's only an exercise in
parsing the history URL.  But whatever.

Tim

Received on Thursday, 14 June 2001 08:21:00 UTC