Next message: Geoffrey M. Clemm: "Re: Target-Selector"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256855.004BAD9D.00@d54mta03.raleigh.ibm.com>
Date: Tue, 28 Dec 1999 08:46:34 -0500
Subject: Re: Target-Selector
But it seems like there is a big difference between COPY and BIND in that
copy does overwrite the contents of the destination meaning that any other
URL bound to the same destination resource will see the new contents. BIND
on the other hand does not change the contents or properties of the
destination, it just gives it a new name. Other URLs bound to the same
resource are uneffected. So it doesn't seem like it should be necessary to
checkout a revision to bind a new URL to it. The collections containing the
existing destination member, and the new destination member would have to
be checked out if they are versioned, but not the resource being bound to.
Right?
If so, then the BIND destination will need both workspace and
override-selector headers.
"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>@w3.org on 12/28/99
12:17:38 AM
Sent by: ietf-dav-versioning-request@w3.org
To: ietf-dav-versioning@w3.org
cc:
Subject: Re: Target-Selector
From: jamsden@us.ibm.com
How does BIND modify the destination? This seems like the one case where
the destination workspace and override-selector headers would be needed
the
most.
A BIND is just like a MOVE, except you don't delete the request-URL.
So the request-URL remains unchanged (i.e. is still bound to the same
resource), but the Destination URL becomes bound to the same resource as
the request-URL. Just like COPY, you can use an Overwrite header to
indicate how BIND should deal with the case where the Destination URL
currently identifies a resource.
Cheers,
Geoff