Re: CHECKIN/CHECKOUT - Mutable resources and a call for consensus
Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Wed, 20 Jan 1999 02:05:32 -0500
Date: Wed, 20 Jan 1999 02:05:32 -0500
Message-Id: <9901200705.AA14162@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: yarong@microsoft.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D08792D50@RED-MSG-59> (message
Subject: Re: CHECKIN/CHECKOUT - Mutable resources and a call for consensus
From: Yaron Goland <yarong@microsoft.com>
> Mutable-Revisions
>
> A mutable-revision is a revision whose contents and properties can be
> changed, although an attempt to change the contents or the "immutable
> properties" of a mutable-revision must be preceded by an explicit
> "checkout/thaw" operation, and then should be followed by a
> "checkin/freeze" operation to return it to a read-only state. This
> then requires two flavors of checkout: a checkout that unfreezes an
> existing mutable-revision (which I'll call CHECKOUT) and a checkout
> that creates a new (unfrozen) mutable-revision that is based on an
> existing mutable-revision (which I'll call CHECKOUT-NEW).
This paragraph leads me to two questions:
1) Should mutable resource management be in-scope for
WebDAV?
When looked at "properly" they are just a natural simplified subset of
immutable resource management, so I'd say, yes.
2) Are the mutable resource and versioning models similar
enough to justify worrying about their interoperability?
Yes. Both use checkout/checkin to handle multi-author control,
and both allow creation of additional mutable resources (branches)
to handle parallel work.
I do not believe that WG consensus exists on the answer to question 1. There
was discussion on the issue amongst the original WebDAV authors but no
conclusion was ever reached as versioning work was shut down in favor of
solidifying the rest of the spec. Consequently the issue was never presented
to the WG for discussion and consensus.
As for question 2, I would be very interested in hearing the reasoning
behind the versioning authors' opinions on these matters. A presentation of
the versioning model and a separate presentation on the mutable resource
management model with a compare/contrast between the two would probably go a
long way to clarifying the issues.
Fair enough. We'll produce such a presentation following the imminent
design meeting in Utah.
Until the versioning authors have a chance to respond I would offer the
following as food for thought:
A versioning client may be willing to use core WebDAV methods such as
PROPFIND/PROPPATCH and GET against a mutable resource server. But such a
client could not, for example, pull down the history of a mutable resource
since the client's fundamental assumption is that while a history can be
expanded its existing relationships can not be changed.
Note: I'll use the terms:
"mutable-revision client" and "immutable-revision client"
rather than "mutable resource client" and "versioning client".
A mutable-revision client can pulldown the "mutable history", where
mutable history contains the information about what mutable-revision
was the "base" for another mutable-revision.
An immutable-revision client can pulldown the "mutable history"
(i.e. the "branch history") or the "immutable history" of the
versioned resource.
Additionally, such a
versioning client would most likely not want to execute check-in/out against
a mutable resource server given that the result is not a versioned resource.
Thus a versioning client can not fully interoperate with a mutable resource
server.
I disagree. If there are importand documents that are stored on a
mutable-revision server, then you'd like to just use your immutable-revision
client just as you always did. You wouldn't be able to retrieve the
immutable-history of the resource, but you can do a CHECKOUT, or if that fails
because some other client already had it checked-out, you can do a
CHECKOUT-NEW to get a new mutable resource (although you might think
of it as a branch). You then do a CHECKIN when you are done, and you
have published your work, just as you would against an immutable revision
server.
A mutable resource client is likely to be more flexible in dealing with a
versioning server.
I'm not sure what you mean by "more flexible". Every mutable-revision
protocol sequence (in this proposal) can be applied against an immutable-
revision server, with the intended results. It just would produce some
immutable revisions as a side-effect, but this wouldn't be visible to
the mutable-resource client.
It certainly can use the core WebDAV commands and will
have no problem pulling down a history.
The history it would pull down would be the "mutable revision history",
not the "immutable revision history" (although it could find the latter
with a suitable manual search through the appropriate properties).
It will run into trouble, however,
when it tries to use check-in/out since the user is expecting that they can
change resources.
No, an immutable revision server will also support the notion of a
"mutable revision", either with a floating label, or with branches,
or with change-sets, or whatever (up to the server).
Still, one can see mutable clients working around this
problem fairly easily since it is a similar problem to access control. Thus
a mutable client can interoperate, almost fully, with a versioning server.
Make that "fully", and we agree (:-).
Thus it would seem that mutable clients should be able to interoperate with
versioning servers but not the other way around.
An immutable-revision client can do all its standard checkout/in against
the mutable-revision server, and can then get the mutable revision history.
It just won't be able to get the immutable history, because it wasn't
being kept. But I can still use my immutable-revision client effectively
(and in the standard way) agains a mutable-revision server.
This argues for separating
versioning design from Mutable design. This could mean breaking the speak
into two parts or even just having two separate specs. [Insert standard
disclaimers about not doing anything gratuitous in the versioning standard
which make it impossible to layer the mutable standard on top.] [Insert
standard disclaimers about not allowing the versioning standard to be
unnecessarily complicated for the sole purpose of making the mutable
standard designer's jobs easier.]
It provides far better interoperability if you have levels of protocol,
where one level is a proper superset of the other (as WebDAV sits above
HTTP-1.1). Since immutable-revisions inherently provide a service not
available to mutable-revisions (namely reliable history and effective
merge support through common ancestor calculations), the layering that
provides better interoperability is layering immutability above mutability,
not the other way around.
Cheers,
Geoff