Removing a resource: A compromise that satisfies?

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