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 17:42:02 -0700
Message-Id: <5.1.0.14.0.20010613165156.029cbc58@10.31.11.235>
To: "John Hall" <johnhall@evergo.net>, <ietf-dav-versioning@w3.org>
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 20:40:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:41 GMT