RE: Removing a resource: A compromise that satisfies?

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