checkout/checkin/uncheckout vs. lock/unlock
Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Tue, 3 Nov 1998 13:29:44 -0500
Date: Tue, 3 Nov 1998 13:29:44 -0500
Message-Id: <9811031829.AA27687@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
Subject: checkout/checkin/uncheckout vs. lock/unlock
Why was the checkout/checkin/uncheckout functionality assigned
to the lock/unlock methods? As I recall, in our last meeting,
we agreed (or at least, all of us but Chris agreed, and Chris
reluctantly accepted :-) that they each really needed to be a
separate method.
There was a proposal to allow you to optionally "lock" a working
resource as part of the checkout command (which is fine with me),
but making the checkout command actually be a variant of the "lock"
makes no sense to me.
- What if you want to leave the working resource available for anyone
to modify? In what sense have you created a lock?
- When you checkin a resource, you have now made an immutable revision.
In what sense have you "unlocked" anything?
- Converely, when you "uncheckout" a working resource, you delete it.
In what sense have you "locked" anything?
- When you "checkout" a versioned resource, you create a new (working)
resource. A "lock" is not something you expect to create a new resource.
So I propose that we not overload lock/unlock, but that we have 3 new
methods: CHECKIN, CHECKOUT, UNCHECKOUT.
Cheers,
Geoff
Note: my previous message to ietf-dav-versioning@w3.org appears to
have been distributed fine (or at least, it make it back to me with
no trouble. So whatever problem Chris was having seems to have either
been fixed, or is a local problem at his home mailing site.