Re: WeDAV Versioning Summary - Factoring!
jamsden@us.ibm.com
Sun, 23 May 1999 08:03:13 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525677A.0042706D.00@d54mta03.raleigh.ibm.com>
Date: Sun, 23 May 1999 08:03:13 -0400
Subject: RE: WeDAV Versioning Summary - Factoring!
Yaron,
Lots of good comments that all of us on the versioning working group agree with.
We have introduced leveling in the versioning protocol, and spent many long
hours figuring out how many levels there would be, and what would be in the
levels. The versioning summary attempts to give an overview of the complete
semantics so that we can do the leveling with those semantics in mind. We don't
want the lower levels to introduce things that are in conflict or redundant with
things in the higher levels.
I think you will find that DAV versioning level 1 will meet most needs. Level 1
includes simple versioning, labeling, and the ability to get a revision history.
Workspaces are included, but without activities or a revision selection rule.
They are only used to distinguish checked out working resources, something like
a "checkout token". This level should be fairly easy to implement and
corresponds to the minimal versioning semantics supported by most existing
systems.
Note that what is simple for the server often translates to complexity for
clients and/or users. We are trying hard to strike a balance between server
complexity, client complexity, usability, interoperability, and conformance to
existing systems. This is a hard task with conflicting requirements, but I do
think we are achieving a good balance. Its real easy to say I just want
versioning. But then, you have a multi-version space and usually want a
single-version view, one where your changes aren't mixed in with others in an
uncontrolled way. So workspaces get introduced. Then this is the web with lots
of users distributed over a broad network, so you want controlled parallel
development with maximum resource availability. This introduces the need for
some way to defer conflicting changes and resolve them later - merging.
Activities provide a way to manage these changes and merging in a simple,
scalable way. Finally, you've got all these revisions of all the resources and
you need some way of preserving a specific set of specific revisions that have
been tested and work together. Configurations provide this important function.
So it doesn't take long for things to get complicated.
Much of the complexity of DAV versioning is in the process of determining what
is in DAV versioning rather than the result itself. The versioning summary is
getting a little long, but I suspect that as we get further down the road,
things will simplify some more. The process isn't finished yet, so some of the
process complexity is still in the documents.
Yaron Goland <yarong@microsoft.com> on 05/21/99 06:55:33 PM
To: Jim Amsden/Raleigh/IBM@IBMUS, ietf-dav-versioning@w3.org
cc:
Subject: RE: WeDAV Versioning Summary - Factoring!
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. 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?
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?
Question 3 - Would Delta-V be a failure if the base versioning case didn't
support workspaces?
Question 4 - Would Delta-V be a failure if the base versioning case didn't
support configuration management (read: can't version collections)
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.
In DAV we had a motto that really fits this situation well "The spec is done
when there is nothing left to cut." I would start by cutting mutability and
work from there.
Yaron