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.

   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.  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.

   > 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.)

   > 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?

Cheers,
Geoff

Received on Friday, 15 June 2001 10:45:34 UTC