Re: WeDAV Versioning Summary - Factoring!

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Fri, 21 May 1999 23:44:22 -0400 

Date: Fri, 21 May 1999 23:44:22 -0400
Message-Id: <9905220344.AA05803@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D0879322C@RED-MSG-59> (message
Subject: Re: WeDAV Versioning Summary - Factoring!


   From: Yaron Goland <yarong@microsoft.com>

   In general the versioning specification has grown so feature laden that I
   despair of very many groups ever being able to actually create a WebDAV
   compliant versioning system.

Something which probably wasn't made clear is that the versioning summary
Jim posted is full "level 2" or "configuration management" versioning.
In the protocol, we identify a "level 1" or "version management" protocol
which is *much* simpler subset of level 2 functionality.  Yaron's suggestions
are very close to the current level 1 specification (and in some cases,
it has even less than he asked for :-).

   I think the problem is factoring. Here are some
   heretical questions:

   Question 1 - Would Delta-V be a failure if the base versioning case only
   allowed HTTP/1.1 and WebDAV Level 1/2 clients to read but not change a
   versioned store?

An HTTP/1.1 client should sufficient to be able to read a versioned-store
(one of my motivations for representing the history of a versioned-resource
as a collection), and to have limited write capability (the "auto-version"
property on a versioned-resource).

   Question 2 - Would Delta-V be a failure if mutability was punted off to a
   completely separate specification so that the majority of systems which only
   have to deal with versioning can concentrate just on versioning?

We've narrowed the impact of "mutable revisions" on the protocol to be
very small.  If after reviewing the protocol you still feel the impact is
too great, please let us know (not that I thought you wouldn't :-).

   Question 3 - Would Delta-V be a failure if the base versioning case didn't
   support workspaces?

In the "level 1" case, workspaces effectively provide a "checkout token"
and are the only way to identify a working resource, so they couldn't be
deleted.  Using a workspace to support user-defined version-selection
rules isn't required until level 2.

   Question 4 - Would Delta-V be a failure if the base versioning case didn't
   support configuration management (read: can't version collections)

Level 1 does not support versioned collections.

Level 1 also does not support activities or configurations!

So basically, level 1 is just versioned-resources, revisions, labels,
and workspaces.  The new methods are CHECKOUT/CHECKIN/UNCHECKOUT/MKRESOURCE.

   Today Delta-V is turning into a monster with more features that anyone save
   the very highest end vendors could ever hope to support. I know of at least
   one million+ line operating system that is being developed using a
   versioning system that can't version collections, doesn't allow down level
   clients to make changes, doesn't support work spaces, has no clue what the
   hell a "mutable" resource is, wouldn't know an activity if it hit it between
   the eye balls and can't even generate explicit histories! Yet the system
   works and unbelievably complex products manage to ship. Clearly there is a
   strong and thriving market for low end versioning systems. My fear is that
   even the "basic" Delta-V system will be too complex. Even the summary took 7
   bloody pages! How can anyone ever hope to every perform a comprehensive
   review of such a complex spec much less implement it? I am having ISO
   flashbacks. Those guys produced the best specs nobody could implement.

Hopefully level 1 is more what you had in mind.

Note also that the new resource types in level 2 have been designed to
be as orthogonal as possible, with the idea that a vendor should be
able to supplement their level 1 server with a subset of the level 2
resource types.

For example, they could just add a "configuration", or just add the
ability to put a revision-selection-rule in a workspace, or just add
the notion of a vesioned-collection.  In this way, they could ensure
that their client/server provides the appropriate level of functionality
for their customers, while knowing that any level-1 client could run
against their server, and their client can run against any level-2 server.

Cheers,
Geoff