RE: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt

At 22:39 2/8/99 -0800, Chris Kaler wrote:
>[CK] In the -00 draft it was proposed that CHECKOUT/IN use the LOCK method
>        since the behavior is very similar to locks.  The working group
>        decided against this.  Note that this style approach would resolve 
>        your issue above as well.  Maybe we should model this as LOCK and 
>        return a checkout token as you suggest.  This token would then 
>        be passed in on CHECKIN.  I guess the question I have then is,
>        how is this different from LOCK?

LOCK gives you a token that may expire at any time for mysterious reasons.
CHECKOUT should give you a token that persists until CHECKIN or 
UNCHECKOUT.  

There are a couple of ways to look at CHECKOUT.  One is Geoffrey's 
"A CHECKOUT makes a readonly URL writeable.  A LOCK restricts who can
write to a writeable URL."  In this case, for the usual source control
functionality, you would LOCK a resource, then perform a CHECKOUT, and no 
one else would be able to do anything until you perform a CHECKIN and 
UNLOCK it.  If you simply did a CHECKOUT, *anyone* could write to
the resource, and *anyone* could do a CHECKIN on it.

The current proposal for CHECKOUT does not restrict the number of
CHECKOUTs against a single resource.  The reason I suggested a 
CHECKOUT token is that you would be able to maintain this functionality
if you received a Checkout-Token on doing a CHECKOUT.  Any access
of a given URL with the appropriate Checkout-Token for the URL will
get you the data pertaining to that CHECKOUT-- you can PUT and PROPPATCH
using the Checkout-Token all you want, until you perform the CHECKIN.

If you have multiple checkouts of the same file, the first person to
do a CHECKIN creates the next version; at this point, all other people
with CHECKOUTs of the file have to either BRANCH from the version they
checked out, perform a CHECKOUT of the new version, UNCHECKOUT the
old one, make the changes to the new version, and do a CHECKIN, or
apply the new version's changes to their current CHECKOUT and 
do a CHECKIN with the Override-Checkin header turned on.  (This
appears to be the behavior in section 3 of the latest document,
anyway.)  They find out about this when their CHECKIN fails--
presumably with 412 Precondition Failed? 424 Failed Dependency?
409 Conflict?

>[CK] If they live anywhere in the namespace, getting a list of the defined
>        configurations is quite hard.  That was the idea for putting them 
>        in a "well known" place.

Is there a need to get a list of defined configurations?  If the
header you're passing for a configuration is the URI of the configuration
on that server, there's no extra time spent in looking it up.

>[CK] Our idea was that a the /c/Beta1 would contain references to the
>        resources in the configuration.  If a configuration contains 
>        another configuration, how would you represent that?

If a configuration is something you navigate into because it is,
in itself, a view of a project, it makes sense to have subconfigurations;
if it is just a token you pass in so you see a particular version 
when looking at a given URL, it no longer makes sense to have 
subconfigurations.

>[CK] Its clear that we need much more verbage in the document.  I'm not sure
>     I followed the "logging in" part.

I'm considering the way that configurations would manifest at a
user interface level.  At some point, the user needs to tell their
software what configuration to use for accessing a server.  The choice
of configuration would be the equivalent of acquiring an environment
when logging in to a machine.

If a user is attempting to do work involving two different configurations
on the same machine, things could get complicated when persuading their
interface to switch back and forth.  For instance, consider the case where
a project has been BRANCHed after the 1.0 release.  One branch is
used for bug fixes to the 1.0 code, while the other is used for developing
the next 1.1 release.  If a bug is found that needs patching in both
branches, it should not be immensely difficult for a user to switch
back and forth between configurations.

Another, similar case is the one for two projects that need related
changes made-- such as to a WebDAV client and server when a new document
comes out from the working group. :-)  One configuration exists for
the client, and another for the server.  Many programmers would 
implement each feature in turn on the server and the client, testing
as they go, rather than implementing them all on the server and then
all on the client.  If all files remain checked out the whole time,
that might not be too hard, but if the programmer does a check-in after
each feature has been implemented and tested on both ends, it could
be a lot of work to keep switching configurations between the one for
the client and the one for the server. 

>What other information would go in with SETDEFAULT?  For that matter, is
>SETDEFAULT really doing anything you couldn't with PROPPATCH?  If I'd read
>that SETDEFAULT functionality was to be implemented with a live property
>named DAV:defualtversion, I wouldn't have blinked...

>[CK] We debated this one for a while.  The issue really comes up with
>        references.  

Aha.  It might be good to explicitly call out references for
"If a resource is shared, servers MUST support the ability to set
different default revisions at each point of the share."

-- 
%% Max Rible %% max@glyphica.com %% http://www.amurgsval.org/~slothman/ %%
%% "Before enlightenment:  sharpen claws, catch mice.                   %%
%%  After enlightenment:  sharpen claws, catch mice."            - me   %%

Received on Tuesday, 9 February 1999 14:11:16 UTC