W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

Re: Removing a resource: A compromise that satisfies?

From: Rick Rupp <rick.rupp@merant.com>
Date: Wed, 13 Jun 2001 15:13:40 -0700
Message-Id: <>
To: "John Hall" <johnhall@evergo.net>, <ietf-dav-versioning@w3.org>
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" ?>
>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.
Received on Wednesday, 13 June 2001 18:11:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC