RE: A compelling use case ...

First, I'd like to emphasize that I agree with the following 
statements:
- the protocol should support the explicit deletion of versions
(although a server may refuse the deletion request)
- servers will provide some mechanism for reclaiming space
(possibly involving auto-archiving, and maybe even auto-deletion).

There appear to be three questions in this thread:

- Should we define two different behaviors that a server can
perform in response to a "plain" (i.e. no request body or
additional headers) DELETE does when applied to a VCR?

- If the answer to question 1 is "no", then should the defined
behavior be "keep all versions" or "delete all versions".

- Should we extend the DELETE request with a body that says either
"delete all versions of the VCR" and "keep all versions of the VCR".

My responses to these questions would be as follows:

For question (1):

In designing an interoperable protocol, what matters is not what your
users have in mind, since different users will have many different
(incompatible) things in mind, but rather what client writers have in
mind when they have written a client using the protocol.

The job of a client writer is to map the (many different) things a
user might want into the (single shared) semantics defined by the
protocol.  The more "server-selected" alternatives defined by the
protocol, the harder it is for a client writer to do this mapping
in a way to works against a wide range of servers.  We've worked very
hard to narrow these alternatives down to 5 "packages".  To introduce
variant server-selected delete semantics would be a step backward.

For question (2):

- The "delete all versions" behavior is inconsistent with the server
workspace feature, while the "keep all versions" behavior is not
inconsistent
with any other versioning feature (to emphasize, this is talking about
feature consistency, not user wishes, which are always inconsistent
from one community of users to another).

For question (3):

- We already have a way for a server to support efficient
deletion of all versions, by supporting the version-history feature,
so we do not need another way (additional features, even minor ones,
in a complex protocol, further increase the complexity).

Cheers,
Geoff

-----Original Message-----
From: John Hall [mailto:johnhall@evergo.net]
Sent: Friday, June 15, 2001 3:44 PM
To: 'Clemm, Geoff'; ietf-dav-versioning@w3.org
Subject: A compelling use case ...


Geoff Wrote:
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.)

====================================

No, that is not our position / concern.  That you believe it is may have
effected your response.

To me the issues are:
1) Freeing the resources occupied by the data.
2) Default behavior of DELETE.
3) Where should the burden properly fall.

It simply isn't relevant to any of my concerns that other people may
have cached the data, or have links to it.  They can cache it if they
want too on THEIR systems.  And if they link to it they have NO
expectation it will remain in existence unless they hold a lock on it.
That applies to your version-aware clients / customers / users, too.

Tim Ellison wrote:
   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.

And Geoff responded:
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.

My Position:
I'm 100% with Tim Ellison, which is why I offered additional protocol
elements on the DELETE if necessary to resolve the predictability
problem.

Why should it be my clients obligation to jump through hoops to make
"all traces of those versions removed from this site" rather than your
clients obligation to tell the server "keep them around"?  Since a
DELETE on a non-VCR reclaims server space, I think I have the stronger
argument that reclaiming space is the natural default.  And it seems
safe to assume that your server and clients are more sophisticated than
mine, which implies they have a greater burden in being explicit about
what they want to happen.

And as for the users that don't want version references to be broken,
the ONLY recourse they have to set permissions and locks that prevent
delete.  Or restrict themselves to your server implementation.

I don't see your position as protecting these clients, or the ability to
write interoperable clients at all.  It is only protecting them from
having to add the flag "keep-versions" when they do a DELETE.

Jim W:
John, Lisa: Let me note that one of the foundations of your argument in
favor of this capability is an indirect appeal to authority, namely the
authority of your users/customers.

Me:
Granted, and we are going back to those customers to check as we speak.

=================================================
The comments below were created earlier, and I sat on them for awhile.
They may be a good key to my thinking, attitudes, biases, etc. that are
driving my comments on this.  They cover many of the points above, but
with more exposition around them.

=================================================


What is a compelling use case?  To me it is a paying customer with a
reasonable request.

Well, I'm an almost 40 year old engineer with a grad degree.  I may be
wrong, but I've rarely been accused of being an idiot.  And my reaction
is *of course* a DELETE of this versioned file deletes all the old
versions, too.  Why the bloody else would I ask for a DELETE?  Why would
an old version have any life after the file it was an old version of
ceased to be?  Gimme back my server space.

Now if I react that way, how am I supposed to explain the idea that
DELETE doesn't mean DELETE to my typing pool?

To my typing pool, these versions aren't completely separate items.
They are intimately tied to the file in question and they are
meaningless without it. I don't mind your attempts to satisfy a market
where they are viewed differently, but this *is* my market, it isn't an
unreasonable one, and I'd lay bets that it is the larger market.

Look; disk space costs money.  It is a limited resource.  Companies
assign quotas to users.  Most companies DO NOT view adding revisioning
as a dramatically new sophisticated way of looking at things, but as a
small incremental advance.  As such, the default behavior experienced by
users and simple clients that know about versioning should be as close
as possible to a straight DAV server.  If anyone has to stand on their
head to make something work, it should be the more complex clients with
the more complex users, not the members of my typing pool.

And it is particularly bad to say that a DELETE of item A renders items
B through Z effectively undeleteable.  (If I can't find them, I can't
delete them.  Besides, my users thought they already did delete them.).

No client should expect a resource to remain in existence unless it
specifically locks the resource or takes some other action to make sure
the resource is not deleteable.  If my customer tells me that he wants a
system that deletes versions that are 6+ months old and have at least 2
subsequent versions then he should be able to buy software that
implements that decision.  The idea that some other company in Angola
doesn't think information once collected should ever be lost won't
impress him -- the company in Angola isn't paying for his disk drives.

I keep reading that your clients need to 'know' that those versions
haven't been deleted.  Why?  I'm certainly going to allow a user to zap
them one at a time.  Since your client can't know those resources have
not been deleted, we are only arguing about the default behavior -- and
the simplest 'least surprise' 'least burden' response is to make
destroying the old versions the default.

I fail to see the point about Google, and I don't think my grandmother
uses a PC.  If google caches a document, so be it.  They can do whatever
they want when they are paying for the server space.  If they have a
link, ok.  They just might get a 'NOT FOUND' response.  They have NO
guarantee the resource is still there, only that if they do find
something on the unique URL that it is what they thought it was.  The
point about DELETE isn't to destroy the information, it is to free the
resources.

Received on Tuesday, 19 June 2001 07:54:38 UTC