Re: draft of CHECKOUT method

jamsden@us.ibm.com
Thu, 14 Oct 1999 07:26:13 -0400 

From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525680A.003F0BEB.00@d54mta03.raleigh.ibm.com>
Date: Thu, 14 Oct 1999 07:26:13 -0400
Subject: RE: draft of CHECKOUT method



<jra>
But the activities are really effectively still there, they're just
anonymous.
</jra>
<bhs>
You're over my head.  They are not required or necessary even under the
covers.  Please, explain.
</bhs>
<jra>
Activities are effectively the name of predecessor/successor arcs in the
revision history of a resource. When there is parallel development, a revision
has potentially more than one successor, and therefore more than one arc. If
activities are not used, then these arcs have no identity and cannot be
manipulated by the client through the protocol. Activities provide a way to
directly manage multiple lines of descent. I think parallel development without
them will be possible, but more difficult, moving more responsibility onto the
user without mechanisms in the protocol to help. We should realize that just
because a particular repository manager doesn't support the concept of
activities doesn't mean it would be impossible, or even hard, to implement them
in the WebDAV interface to that repository manager.
</jra>

<bhs>
We're talking about adding the <DAV:single-checkout/> element to
DAV:coparams to trigger the same semantics as the DAV:single-checkout
property.
You're saying this makes CHECKOUT harder to understand, use, implement, and
maintain.
That does not seem true to me.
  It is not hard to understand.  It is simply a way for the client to say he
doesn't want to trigger parallel development, even on revisions that allow
it.
  It is certainly easier to use for clients not using activities.  They now
have a simple way to control if they as a single client want to do parallel
development or not.
  The implementation seems straight forward, reusing much of that for the
DAV:single-checkout property.
  No extra maintenance is apparent to me.

Perhaps you are still taking the stance that everyone must always use
activities for all parallel development and therefore this is unneeded
baggage.  If this is where you are coming from then you should be pushing to
make activities required in the protocol for doing parallel development.
Until that day, the protocol can and should support simple non
activity-aware clients and servers as well as activity-based clients and
servers.
</bhs>
<jra>
What I'm suggesting is that we've alread added quite a number of things in the
checkout policy, many of which have to do with checkin providing proactive error
detection. Adding another element or header requires that we look at all
possible combinations of that element or header and all its values with all
values of all other elements and headers to determine the method rules. After a
while this gets pretty difficult for us to determine, and for users to use. I'm
just trying to minimize the protocol and avoid having multiple, optional ways of
doing the same thing.
</jra>