UserA's client could do it in either order. It really doesn't matter.
If the client does the LOCK first, it maximizes the chance that UserA
will beat someone else who's trying to get a LOCK as well, but if
someone else gets in with the LOCK of the checked out resource before
you, it just means you have to wait until they are done to make your
changes.
As for "providing an alternative method", this assumes you have
multiple workspaces or are using working resources. In these
cases, you just do CHECKOUT, update, CHECKIN. No need really for
a LOCK, since you have your own private workspace or working
resource. Of course, you have
to resolve merges in case you ended up doing this in parallel,
so you avoid complexity only in cases where you don't end up in
a merge situation.
If you believe the "avoids complexity" sentence is misleading, let
me know and I'll revise/remove it.
Cheers,
Geoff
-----Original Message-----
From: Steve K Speicher [mailto:sspeiche@us.ibm.com]
Sent: Friday, March 23, 2001 7:08 AM
To: ietf-dav-versioning@w3.org
Subject: Re: DAV:lockdiscovery on a checked-out resource
I guess all this boils down to is that UserA should first do a LOCK then a
CHECKOUT? ...or a CHECKOUT then a LOCK?
But section 4 "CHECKOUT Option" states: "The checkout option provides an
alternative method that avoids the complexity of the locking protocol".
How am I to interpret this sentence based on what I've heard in this
thread?
Thanks,
Steve