RE: Removing a resource: A compromise that satisfies?

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: 15 June 2001 15:51
> To: ietf-dav-versioning@w3.org
> Subject: RE: Removing a resource: A compromise that satisfies?
>
>    From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]
>
>    "Clemm, Geoff" <gclemm@rational.com> wrote:
>    > Before we got much further with this thread, let's
>    > examine the underlying premise that "deleting the
>    > versions when the VCR is deleted" is an important
>    > use case.
>
>    Whether it is an important use case or not, the proposal that you
>    made so far seems relatively harmless since it permits a server to
>    delete versions in a fashion that retains the 'referential
>    integrity' that people wanted.
>
> The problem with the "referential integrity" argument was that it
> assumed that the only version references that mattered were a few
> specific ones (e.g. the DAV:checked-in or DAV:checked-out properties
> of version-controlled resources).  In fact, there might be references
> to those versions stored in a variety of dead properties, or in
> HTML documents, and those references would be broken if the
> version was deleted.

There is always the potential for these references to be broken whenever a
server allows a version to be deleted.  *If* the use case (automatically
cleaning out versions) is proven useful then retaining "referential
integrity" of existing version-controlled resources is useful.

>    Clearly there will be servers that do not allow version
>    deletion at all,
>    and they are free to retain that policy; but for servers that do allow
>    version deletion I do not see significant difference to the server
>    implementing the proposal and a client implementing the same
>    deletion as a policy.  Either way the versions will have gone.
>
> The difference is critical for a versioning aware client that wants to
> provide predictable behavior to a versioning aware user.  If that user
> wants "all traces of those versions removed from this site", then it
> is the clients job to do so.  If that user wants "all references to
> those versions to remain valid", then it is also the clients job to do
> that.

Where a server allows version deletion the client cannot do that job.  It
cannot prevent the client in the next room deleting versions that it
considers important.

> If the versioning protocol defines predictable version deletion
> behavior, the client has a reasonable chance of doing this against a
> wide range of versioning servers.  If it does not define predictable
> version deletion behavior, then for users that don't want version
> references to be broken, the client would have to create its own
> copies of all the versions (in some non-versioning space), and then
> fix up all the references (not an easy job!) to those versions to
> point to those new copies.

Agreed -- I was only stating that, where servers allow version deletion, the
proposed condition could be implemented client-side with existing methods --
and since this is the case there is no good argument against it.  It does
have to be predictable however.

>    > This is the web, so everybody and their grandmother
>    > (and for sure, www.google.com) will have cached copies
>    > of anything you put up on the web, so an argument
>    > that blowing away old versions at server defined
>    > URL's will somehow make that data go away is rather
>    > unrealistic, isn't it?
>
>    I don't buy this argument at all -- the argument for DELETE is not
>    'erase' the data but rather to make it unaccesible (it is a
>    namespace operation)?
>
> Which argument don't you buy?  The one that says that it is important
> for DELETE to erase the data?  Or the one that says that it is
> unrealistic to expect to be able to erase all instances of "related
> information at other URL's" (e.g. old versions) with a DELETE request.
> (The first argument was the argument made by the proponents of the
> auto-delete behavior.  The second argument is a counter-argument to
> this first argument.)

The one that says that it is important for DELETE to erase the data.
"Erasing the data" is not the correct answer in the face of BINDs etc.

>    > And if it doesn't really go away, why do we care that there are
>    > also a few obscure server-defined URL's that contain a copy of a
>    > version of this data?
>
>    The server admin sure cares that there are copies of the version data
>    left on the server.
>
> This is a separate issue.  Yes, the server admin does have to have
> space conservation policies, but I believe that should be provided
> in a general WebDAV context, based on issues like "last time referenced",
> "size", and "reproducibility".
>
>    > So my revised position is that we defer any action on this
>    > proposal until the group reaches consensus that this is in fact a
>    > compelling use case.
>
>    Agreed.
>
> Does your agreement imply that you feel no such compelling use
> case has been brought forward?

Yes.

Tim

Received on Friday, 15 June 2001 16:02:26 UTC