Re: MKRESOURCE results
Tim Ellison OTT (Tim_Ellison@oti.com)
Tue, 21 Dec 1999 12:00:26 -0500
From: Tim_Ellison@oti.com (Tim Ellison OTT)
To: ietf-dav-versioning@w3.org (ietf-dav-versioning)
Message-ID: <1999Dec21.115800.1250.1424459@otismtp.ott.oti.com>
Date: Tue, 21 Dec 1999 12:00:26 -0500
Subject: RE: MKRESOURCE results
<geoff>
I prefer a third alternative: one revision (with default values for all
properties and an empty body) and one working resource (checked out from
that revision. It is the working resource that the PUT or MKRESOURCE is
applied to.
</geoff>
This is going to leave lots of clutter in the version history.
I'm not sure that an empty "root" revision in a revision history
is reasonably classified as "lots of clutter". And as you say
below, any client that feels this is "clutter" can just hide the
initial empty revision.
<tim>
When I tell you that I meant 'if every versioned resource created this way
has a bogus revision then it leads to lots of clutter in the entire
repository', would that be any more reasonable?<g>
I appreciate that we have a different view of 'clutter'.
</tim>
Essentially, every versionable type that was created in a versioned
collection will have a phantom revision that was never intended to be
part of the development ancestry.
The empty root revision often comes in very useful when you have
selected a collection revision that has a particular versioned resource,
but you don't want to select any revision of that versioned resource.
The empty root revision effectively captures "the state of that object
before it had any work done to it".
<tim>
The problem is that the client has to detect that this first revision is
"the state of the object before it had any work done to it" since in general
the client cannot tell whether the resource was created in a versioned
collection or not.
How would a client know that this was a "clutter" revision (I just coined
that phrase to tease you ;-) rather than a genuine revision. The client
would have to know what the default values of the properties were etc. In
general they cannot know.
</tim>
In addition, a variety of operations (such as "compare my contents
to my predecessor") are much simpler to write when there is an
empty initial revision.
<tim/>Agreed. Although for some clients they may discover a predecessor
that they never know they had.
Another example is when you are creating a new baseline for an existing
versioned collection, but it is not based on any previous baseline.
With the empty initial revision, you have a reasonable predecessor.
An analogy is that "zero" is a very useful number to have around.
<tim>
Zero _is_ a useful number to have around, but our "clutter revision" is more
like an 'undefined' and the first CHECKIN by the user is the 'zero'.
(p.s. I don't think we can stretch this analogy too far without getting
bizzare!)
</tim>
I can imagine clients trying to
hide that revision when giving users the option to rollback to an
earlier state.
I agree. Which is one reason I don't see any harm (and do see benefits)
in having an empty initial revision.
<tim>
If you can demonstrate how you'd do this I'd be more convinced that it was a
harmless artifact of the spec.
</tim>
Summary of options thus far,
(a) one revision, no working resource,
(b) one working resource, no revisions,
(c) one revision, one working resource,
(d) change the rules for members of versioned collections, (i.e., no
longer
have to be versions.)
I don't like any of them! but I like the spirit of (b).
"d" stands for "disaster" (:-). In particular, it would require that
workspaces have "coupled" behavior (i.e. changes in one workspace must
be made immediately visible to others, thus breaking most distributed
workspace performance optimizations).
"b" leaves you with "no predecessor of your working resource" and resulting
strange behavior for "uncheckout" (does the versioned resource
disappear?)
"a" leaves you with an initial revision with meaningless content
So I'm a big fan of "c" (for "correct choice" :-).
<tim/> Still hunting for "e"lusive.
Tim