RE: labels as DAV:target values (was Re: Fewer new versioning methods, please!)

Could somebody explain why locking of version selectors is a required
feature?  What is the purpose?  What is the result?  Does it affect
checkouts?  I reason that if it was not possible to lock a version selector,
then it would be possible to use labels as DAV:target values, which seems to
me to be a very useful feature.

I would imagine that the only affect locking a version selector would have
is that it would prevent others from doing a PROPPATCH to one of the version
selector's own properties.  It wouldn't prevent others from checking out one
of the versions related to the version selector; it wouldn't prevent others
from doing a PUT or a PROPPATCH to the version to which the version selector
points (that would have to be accomplished by doing a LOCK on the version
resource, rather than the version selector).  Have I missed something?

Has anybody done some serious thinking, in general, about how they are going
to implement locking interacting with versioning?  What happens when a
versioning-unaware client tries to LOCK a resource, not aware that it is
actually locking a version selector?  Is the behaviour what that client
would expect?

Finally, I wonder why the draft specifically disallows using labels as
DAV:target values.  Just because some implementations would find it
difficult doesn't mean all of them will.  Why not make it optional -- and if
a server doesn't support a value of <D:label>foo</D:label> then the server
can respond with an error meaning "unsupported value given for DAV:target
property".

thanks,
Lisa

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Geoffrey M.
> Clemm
> Sent: Tuesday, October 03, 2000 1:06 PM
> To: ietf-dav-versioning@w3.org
> Subject: labels as DAV:target values (was Re: Fewer new versioning
> methods, please!)
>
>
>
>    From: "Lisa Dusseault" <lisa@xythos.com>
>
>    > From: Tim_Ellison@uk.ibm.com
>    > The target of the version selector is always going to be a
> version URL ,
>    > the protocol does not stipulate the form of a version name
> so it does not
>    > allow for uniquely identifying a version.  Using a label
> would be awkward
>    > to implement in a scaleable fashion since labels can move, so version
>    > selectors would have to re-evaluate which version they were
> targeting.
>
>    Really?  I thought that would be a bug, not a feature.  So if
> I go and move
>    the "beta2" label from version 10 of 'foo' to version 18, the
>    target-selector doesn't automatically update its target, even if I
>    originally based the target-selection on the label "beta2".  Too bad.
>
> Tim's point was that the DAV:target is not a label, but rather
> is a URL that identifies a version.
>
> The reason why we do not allow labels as a DAV:target value is that this
> would mean that a server would have to investigate *every*
> version selector
> that had that label as a target, to make sure that when it moved that
> label, it didn't violate any  of the locks on that version selector.
> This is prohibitively expensive as the number of version selectors for
> a given version history becomes large, and impossible if any form of
> disconnected use is to be supported (i.e. where a workspace can be
> disconnected from the version repository).
>
> Cheers,
> Geoff
>

Received on Wednesday, 11 October 2000 16:27:54 UTC