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

Comments below...  

hopefully my mailer won't munge the file like it did yesterday.
Sorry about that!

-----Original Message-----
From: Max Rible [mailto:max@glyphica.com]
Sent: Tuesday, February 09, 1999 11:05 AM
To: WEBDAV WG
Subject: 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.  

CK>> I can take an infinite lock

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.

CK>> As you point out in the paragraph below, this model doesn't
CK>> support multiple checkouts.  Note that I do not believe this
CK>> is what Geoff meant.  He was using a token to distinguish
CK>> each checkout.

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.

CK>> However, for the case where you need to lock and checkout, which
CK>> I would argue is very common even if you take a shared lock, the
CK>> client needs to track multiple tokens and include them in the header.
CK>> I'm just trying to point out that LOCK and CHECKOUT have very
CK>> similar behavior and would be implemented the same in the server.

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>> Exactly.  We haven't gotten to the level of selecting the
CK>> error condition, although any of the 3 you listed would be
CK>> reasonable.

>[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>> It is not hard to imagine that a client might want to provide
CK>> the user the ability to select a configuration to use.  To do
CK>> so, it must generate a list.  If configurations are anywhere
CK>> in the namespace, then you have to search the entire namespace
CK>> to produce the list.

>[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>> There is still lots of debate here, so let me state this is just
CK>> my view.  I believe configurations, as defined in -01, serve two
CK>> purposes. Dynamic configurations provide a reliable way to select
CK>> specific revisions of identified resources.  Workspace configurations
CK>> provide a way to track changes to related resources.  That is,
CK>> a branch across a project.  In the terms section, we talk about a
CK>> thread as a sequence of changes.  Workspace configurations are the
CK>> related threads of multiple resources.  For example, Beta1 of my
CK>> project.

>[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.

CK>> I see.  However, I think you can easily switch your "view" of the
CK>> the versioning database.

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.

CK>> I totally agree.  From a protocol perspective, it is as easy
CK>> as changing the value of the Configuration-Id header.

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. 

CK>> Although they could use a separate configuration to "stage"
CK>> the visibility of the change.

>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."

CK>> I thought we did.  If we didn't, and I can believe it got lost
CK>> in the editing, I'll make sure it is in the next revision.

Received on Tuesday, 9 February 1999 15:35:41 UTC