RE: Confusion: Removing a resource from version control

Interoperability is achieved by making server behavior
predictable.  If there are two different "reasonable"
behaviors, one needs to chose one behavior as the defined
behavior and ensure that the other behavior can be achieved
by explicit client action.  In this case, the two behaviors are:

- automatically delete all versions from a version history
when a version-controlled resource for that version history 
is deleted.

- keep all versions when a version-controlled resource is deleted.

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

Note that "explicit client action" does not mean "explicit user
action".  A client can expose a user to whatever default behavior
it wishes (e.g. delete all versions), and can achieve that
behavior interoperably against all (compliant) servers.

Alternatively, one can just define every possible server default
as a "server option", and leave it up to the client writer to
discover what kind of server it is running against, and to
modify every action it performs based upon "what kind of server"
it is running against.  But the result of this approach is
that it is too hard to write an interoperable client, so you
just write clients to run against a specific set of server
options, and thus interoperability is not achieved.

Cheers,
Geoff

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


> If the server only supports the version control feature, then there
> is no version history resource visible in the URL namespace, so a
> client wouldn't know if it was deleted or not (:-).  The key here
> is that the behavior of DELETE has to be consistent, whatever
> feature set is supported by the server, so you can't have
> DELETE do incompatible things depending on what versioning features
> are supported (not if you want to make it feasible to write
> interoperable clients).

Then you need to explain in the draft what the interoperable behaviour is
that allows our implementation to clean out version histories automatically,
because that is what our customers want.

lisa

Received on Wednesday, 13 June 2001 14:23:29 UTC