- From: John Hall <johnhall@evergo.net>
- Date: Wed, 13 Jun 2001 15:32:05 -0700
- To: "'Rick Rupp'" <rick.rupp@merant.com>, <ietf-dav-versioning@w3.org>
Why is it a bad solution? Is it still a bad solution if an implementation MAY retain versions if retain-old-versions is not specified but MUST retain them if it is? Why wouldn't that consider a server where version history is important? -----Original Message----- From: Rick Rupp [mailto:rick.rupp@merant.com] Sent: Wednesday, June 13, 2001 3:14 PM To: John Hall; ietf-dav-versioning@w3.org Subject: Re: Removing a resource: A compromise that satisfies? This is a bad solution. It does not consider a server where version history is important. At 6/13/2001 02:35 PM, John Hall wrote: >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 18:32:07 UTC