RE: Removing a resource: A compromise that satisfies?

A server doesn't have to let a client delete version history.  Even if a
client wants that behavior, a server doesn't have to provide it.

What I have proposed is that the default simple client wants its
resources freed and things like version-history deleted when it issues a
delete on a VCR.

But I've protected your right to build a server that keeps old versions,
and the ability to develop smart clients that can tell you they don't
want versions deleted and make it stick, or *suggest* that they delete
old versions and let the server decide.

Those proposals seemed to satisfy my goals and Geoff Clemm's.

I have no objections to a DAV:delete-old-versions element that is
ignorable.

I have no objections to a server returning its decision
(DAV:old-versions-retained, DAV:old-versions-deleted).

If we added those, would it satisfy your objections?



-----Original Message-----
From: Rick Rupp [mailto:rick.rupp@merant.com] 
Sent: Wednesday, June 13, 2001 5:42 PM
To: John Hall; ietf-dav-versioning@w3.org
Subject: RE: Removing a resource: A compromise that satisfies?


When I read your first message I interpreted it to mean a server MUST 
delete the version history unless a DAV:retain-old-versions property is 
included. How does a server that doesn't want version history deleted 
protect itself from the current clients who don't know about this new
property?

I like the wording MAY retain versions however that still does not
provide 
explicit server behavior. The client really isn't aware what the server
has 
done with the versions in the version history.

If a server only supports version-control, how does a client delete 
version-history if that is what it wants to do? When the
version-controlled 
resource is deleted the version-history associated with it is in effect 
lost on the server isn't it?

At 6/13/2001 03:32 PM, John Hall wrote:
>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 21:05:23 UTC