- From: Clemm, Geoff <gclemm@rational.com>
- Date: Wed, 13 Jun 2001 14:22:51 -0400
- To: ietf-dav-versioning@w3.org
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