Re: DAV:lockdiscovery on a checked-out resource

Jim Amsden wrote:
> If UserA does a CHECKOUT, the resource won't be locked, it will just be
checked
> out.  PROPFIND on DAV:lockdiscovery won't show any locks to anyone.

Actually, the resource will have the same locked status as before the
CHECKOUT.

> Now UserB doesn't know anything about versioning. If UserB just looks for
> locks and upon not finding any assumes the resource is writable, the
write
> will fail because the resource is already checked out.

Being checked-out does not make writes fail!  I'm not sure what you were
thinking of here Jim, but when User B shows up, there is a checked-out VCR
so, from a versioning point of view it is mutable.  The fact that it was
User A that did the CHECKOUT and User B that does the PUT is irrelevant in
the versioning story.  (Of course there is still the lock status that
existed before the checkout and acls etc to clear before you can be assured
that the write will succeed.)

> LOCK will also fail for the same reason, it tries to do an implicit
checkout.

LOCK doesn't do an implicit CHECKOUT -- ever.  Are you thinking of
auto-versioning of a checked-in version-controlled resource?

> We assume that versioning unaware clients are not DAV unaware. That
> is, they can use PROPFIND and look at properties, including properties
> that indicate something is checked out.

Within the versioning protocol we don't assume that version unaware clients
have any knowledge of the versioning properties to make things work, and we
have not put any such requirements on RFC2518, so I'm not sure what you
mean here.

> Its actually the user that's interperting this
> information, not the client. The client doesn't have to support any
> versioning specific protocol to access these properties. Although
> such clients make their users do extra work.

That would require the user to be versioning aware, which is almost the
same thing.

Tim

Received on Friday, 23 March 2001 03:54:59 UTC