RE: Confusion: Removing a resource from version control

A server can of course delete old versions.  It can delete
any resource that it wants to (anything older than 6 months,
anything named "core", anything authored by "geoff" (:-),
whatever).  The question is what kind of expectation should
a client have for persistency of data.  If servers delete
versions as soon as a version-controlled resource is deleted,
a client would have to "save" any versions it cares about in
some other location before it deletes the version-controlled
resource.  If servers do not delete versions as soon as
a version-controlled resource is deleted, the client would
have to explicitly delete the versions it wanted deleted.
The more such "server options" are supported, the harder
it is to write an interoperable client, and the less likely it
is that anyone will be able to do so.

So I disagree that "DeltaV MUST support both" (i.e. leave this
as a server option).  To the contrary, if we care about
buiding interoperable clients, it should specify one behavior
or the other.

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Wednesday, June 13, 2001 2:37 PM
To: Clemm, Geoff; ietf-dav-versioning@w3.org
Subject: RE: Confusion: Removing a resource from version control 



> If the defined behavior is to keep all versions, then the other
> behavior can be achieved by the client explicitly deleting
> the versions when deleting the version-controlled resource.
> But if the defined behavior is to delete all versions, the other
> behavior cannot be achieved by any explicit client action
> (the versions are deleted and cannot be brought back).

Normally I'd agree with what you're saying, but cleaning up old versions can
be server policy.  Server administrators can't force clients to do that, so
it must be a possible server behaviour.

I understand it can also be server policy to keep around all old versions
and NEVER delete them.  That's why DeltaV MUST support both.

lisa

Received on Wednesday, 13 June 2001 15:00:05 UTC