Re: CHECKIN/CHECKOUT - Mutable resources and a call for consensus
Yaron Goland (yarong@microsoft.com)
Tue, 19 Jan 1999 20:58:51 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792D50@RED-MSG-59>
From: Yaron Goland <yarong@microsoft.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>,
Date: Tue, 19 Jan 1999 20:58:51 -0800
Subject: RE: CHECKIN/CHECKOUT - Mutable resources and a call for consensus
This is the second part of my comments on Geoffrey's spec.
>
> 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?
2) Are the mutable resource and versioning models similar
enough to justify worrying about their interoperability?
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.
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. 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.
A mutable resource client is likely to be more flexible in dealing with a
versioning server. It certainly can use the core WebDAV commands and will
have no problem pulling down a history. It will run into trouble, however,
when it tries to use check-in/out since the user is expecting that they can
change resources. 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.
Thus it would seem that mutable clients should be able to interoperate with
versioning servers but not the other way around. 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.]
Yaron