Re: CHECKIN/CHECKOUT - Versioning Policies?

David G. Durand (dgd@cs.bu.edu)
Wed, 20 Jan 1999 10:20:13 -0500


Message-Id: <v04011703b2cba1fdeca3@[24.0.249.126]>
In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D08792D52@RED-MSG-59>
Date: Wed, 20 Jan 1999 10:20:13 -0500
To: ietf-dav-versioning@w3.org
From: "David G. Durand" <dgd@cs.bu.edu>
Subject: RE: CHECKIN/CHECKOUT - Versioning Policies?

At 12:15 AM -0500 1/20/99, Yaron Goland wrote:
>Welcome to the fourth and final entry in my series of comments on Geoffrey's
>proposal.
>Client versioning policy? I thought we killed this back in '97!
>
>In December of 1996 Andre van der Hoek put forward a post to the list that
>summarized a proposal he had made previously to the authors
>(http://lists.w3.org/Archives/Public/w3c-dist-auth/1996OctDec/0199.html). In
>essence it proposed that clients be allowed to tell servers what their
>versioning policy is.

This is not Geoffrey's proposal. Again, some stuff hasn't been written down
yet, but the version selection rule mechanism will be a requirement for
configuration-level servers -- all clients and servers will have a common
language for policy (albeit a very restricted one).


>The issue was investigated, at length, by the working group and the proposal
>was rejected in its entirety. The reason for the rejection was as follows:

This is a different proposal.

>1) Many DM vendors indicated that their users demanded the ability to
>specify a single versioning policy for their server and would demand that
>all clients that interoperate with their server must use that versioning
>policy. The key issue wasn't the particular policy the server used so much
>as the ability of the server to absolutely rely upon a particular policy
>always being used across all its resources. Without this guarantee it became
>impossible to apply meaningful security policies and to interoperably share
>versioning data across resources since the knowledge needed to understand
>the information changed based on which client used which policy against
>which resource. Matters became especially bad if clients were allowed to
>change the policy on a resource once the policy had been established.

This simply isn't relevant to the current proposal, which has to do with
configuration management, and not the Document Management level of the
protocol.

>2) Client vendors indicated that their clients would be written to use a
>particular versioning policy and would refuse to interoperate with any
>server which did not implement that policy. The basis of their reasoning was
>that the UI the client implemented had to be tuned to a particular policy.
>If the policy could change based on the resource being talked to then the UI
>would have to change with it. Furthermore, it is hard enough to write a
>client which supports a single versioning policy. It is next to impossible
>to write, debug, document, and then educate one's users about a client whose
>policy could change on a resource by resource basis.

>At the same time the WG got an "in your face" demonstration of just how bad
>variable policies could be in terms of code and protocol complexity. After
>Andre's post in Dec '96 there was a WebDAV WG meeting in Irvine in Jan '97.
>At the time the various DM vendors refused to compromise in how versioning
>worked. Each insisted that versioning must work exactly the way their system
>implemented it. For example, we couldn't get consensus on an issue as simple
>as "if you do a check out is there a working draft? If so, is it created on
>the server or the client?" So Jim and I presented a protocol that did
>everything everyone wanted. I only think it required three round trips and 8
>different axis's of negotiation. You can see some of the discussion on both
>client versioning and policies and on the versioning design noted down as
>part of day two in
>http://www.ics.uci.edu/%7Eejw/authoring/irvine/minutes.txt. Unfortunately
>the meeting notes don't do a great job of recording the discussions that
>various comments sparked. Those of you who really enjoy pain can check out
>section 9 of http://www.ics.uci.edu/~ejw/authoring/webdav-draft-06.html for
>the details. Try not to laugh/cry too hard.

We have a fair cross-section of these communities in the current group, and
are making progress. Jim is at each meeting, and has not claimed that we're
running down exactly the same path as before, so I think there must be some
differences.

furthermore, things are much more layered now, so that people can choose to
implement just base WebDAV, DM-style versioning, or Configuration
management. We are constrained to make the protocol workable (as far as
possible) with the levels lower down, and currently we are managing this.

So I move that blanket objections based on the past history of other
proposals be avoided, and that we stick to concrete issues with the current
proposals.

>But the point was made, negotiation and variable policies didn't work. While
>I realize that the policies discussed here are not the same as those
>discussed in the document I believe the line of reasoning that made us
>reject policies in '97 will lead us to the same conclusion in '99

Then you'll have to present an argument to that effect. This is indeed so
unlike the kinds of things that "versioning policy" referred to back then,
that the relevance of those discussions seems almost nil to me. I was
there, and in fact it was those fruitless discussions (and the chance to
contribute to XML) that made me leave DAV at that time.

>Either way, in '97, the WG consensus was that there would be no negotiation
>on versioning policy. Neither clients nor servers would be allowed to
>dictate policy. Rather the WG instructed the authors to come up with a
>single policy and make that the standard.

Since that is what we are doing, I don't see that there's a problem.

  -- David
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________