- From: John Hall <johnhall@evergo.net>
- Date: Wed, 13 Jun 2001 14:35:28 -0700
- To: "'Clemm, Geoff'" <gclemm@rational.com>, <ietf-dav-versioning@w3.org>
Ok, then have the versioning aware client specify exactly the behavior it expects. DELETE /foo.txt Is issued by version unaware clients and version aware clients that wish to delete a resource completely. DELETE /foo.txt <?xml version="1.0" encoding="utf-8" ?> <DAV:retain-old-versions/> Is issued by version aware clients that wish to see the VCR removed but not old versions die. Doing this seems to satisfy both of our requirements. We want to make sure that there is a small burden on simple clients, and you wish to retain consistency, predictability, and flexibility in more sophisticated clients. -----Original Message----- From: ietf-dav-versioning-request@w3.org [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Clemm, Geoff Sent: Wednesday, June 13, 2001 1:54 PM To: ietf-dav-versioning@w3.org Subject: RE: Confusion: Removing a resource from version control From: Lisa Dusseault [mailto:lisa@xythos.com] To rebut the earlier argument that clients need predictable behaviour -- well sometimes that goes by the wayside. After all, that's what 404 Not Found was invented for. Things disappear. Having the server provide predictable behavior for a versioning unaware client (and for that matter, a versioning unaware user) is necessary but far from sufficient. The hard part is to also support an interoperable versioning-aware client for versioning aware users. A versioning aware user knows (and cares) whether old versions are kept or not. A versioning aware client needs to do what the versioning aware user wants (not just some random behavior selected by a versioning server implementer). So that means if the versioning aware user wants the versions to be deleted, the versioning aware client needs to somehow delete those versions. Similarly, if the versioning aware user wants the versions to be kept, the versioning aware client needs to somehow save those versions. If the protocol defines the deletion behavior, an interoperable versioning aware client can be written to produce whatever versioning behavior the user expects. If the protocol leaves deletion behavior up to the server, then an interoperable versioning client would need to determine what behavior the server has chosen to implement, and then have separate code paths to deal with each of those behaviors (in order to produce the effect expected by the versioning aware user). Note: If you primarily care about producing a specific behavior for versioning *unaware* clients, and you don't care much about interoperability with versioning *aware* clients, then you can just support HTTP or 2518 WebDAV, and implement whatever versioning behavior you want. But if you want to support interoperability between versioning aware clients, then you only get that by defining explicit behavior for the server that versioning aware clients can count on when they are implementing versioning behavior for a versioning aware user. Cheers, Geoff
Received on Wednesday, 13 June 2001 17:35:29 UTC