Next message: Clemm, Geoff: "draft-ietf-deltav-versioning-04.2"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568BB.005962CF.00@d54mta03.raleigh.ibm.com>
Date: Sat, 8 Apr 2000 12:16:15 -0400
Subject: Versioning 4.0 review
The only modification I'd make to your description is that when a workspace
is not specified on a checkout, the server "allocates" a workspace ... it
does not necessarily have to create a new workspace. This allows an
advanced
versioning server to "reuse" workspaces to handle core versioning CHECKOUT
requests.
<jra>
If the server reused workspaces when one wasn't provided, there would be
the possibility of collisions from multiple users. I don't think this would
work.
</jra>
But note that a core versioning server is only required to
support the "server allocates the checkout workspace" mechanism.
Chris has requested this, and I believe we agreed to it. An
advanced versioning server may optionally support a user creating a
workspace resource and specifying that with the CHECKOUT request.
<jra>
I think core versioning will want to do this too. Then Chris can reuse the
same checkout token for lots of resources having related changes. That is,
the server should only allocate a workspace checkout token if no workspace
was specified on checkout. If one was provided, then it can be reused. This
should be in core versioning. It has no implications about workspaces being
used for anything but identification of working resources. Note there is no
implication that creation of workspaces needs to be in core versioning,
only their use on checkout.
</jra>
Is the approach of
"core versioning uses a SET-DEFAULT-REVISION and advanced versioning
allows the use of MERGE for activities and baselines" acceptable
(it certainly is much simpler and more consistent).
<jra>
I don't think so. Let's devote a call on the subject of default revision
selection after we've settled some of the non-default behavior of
workspaces.
</jra>
I'll let you and Jim Whitehead hash this out ... he didn't like
DAV:revision and DAV:revisions because they'd be easy to confuse.
<jra>
Then English is too easy to confuse. In any case, end users are not going
to be setting these headers anyway, only client applications. I say keep
them short, keep them to single words when possible, avoid abreviations,
and use commonly used language and domain terms and grammar.
</jra>
- 5.1 Postconditions is worded kind of funny. "If the response status
code
is 201..." On successful execution, the resource is created with an empty
body and its properties initialized as given in the request entity body.
Last paragraph: If execution fails, no new resource is created and any
resource that may have existed at the request-URL is unaffected.
Why is a reference to the status code funny? That is more concrete than
"if the execution fails".
<jra>
Just that usually the method semantics are described based on what happens
to the repository and status codes are described at the end to indicate
exception conditions, etc. This one turns it around and describes the
semantics in terms of the status codes first. Just a style issue, but
consistency is truth, and I don't like semantics described in terms or
enumerated status return values. Just doesn't feel right.
</jra>
I think the whole business of removing a merge arc is probably bogus
(I think I suggested allowing it, so we know who to blame :-).
The likelihood of you wanting to do that is so small that I think it
is easier to just do an uncheckout in that case, and start the merge
over again. Anyone object?
<jra>
I have lobbied for this since the FileNet meeting. But I got convinced that
since merge is actually an operation/process that requires client input,
one might want to "cancel the merge" so that it can be done over again. I
have done this many times, but always by createing a new working resource,
overwriting it with the contents of the previous revision, and doing the
merge again. Maybe this is fine for the few times it will be necessary.
</jra>
If we have no revision selection rule, but only a baseline list
(which is guaranteed to be immutable), we can avoid the whole topic.
We've discussed this somewhat, but I'm sure we'll discuss it some more
(:-).
<jra>
I don't think we should give up on dynamic workspaces and revision
selection rules. Instead I think we should add the concept of static
workspaces to give more implementation flexibility at some loss in client
flexibility.
</jra>
...say "to merge from a workspace, you first have to create a baseline
in that workspace, and then merge that baseline". This has the
further advantage that it leaves the destination workspace in a much
more predictable state.
<jra>
This sounds reasonable.
</jra>
I think we currently have settled on removing "configuration", since it is
redundant with "workspace". Then a baseline is just a revision of a
versioned workspace.
<jra>
I'm not happy with this. I still think workspaces and configurations are
different. To me its a question of modeling changes in behavior as state
dependent behavior of the same object, changing to a subtype, or using
different objects. Often this is a judgment thing. The reason I'm leaning
away from having configurations/baselines be revisions of a workspace is
that I think it couples too many, perhaps complicated, concepts into one
mechanism. This may make the versioning model more difficult to understand.
</jra>
- 10.5.1 Perhaps there should be a way to list all the members of a
workspace, not just the working resources.
That's a pretty big report! Also, they will just be revisions
shared with many other workspaces, unlike the working resources that
are owned by the workspace.
<jra>
Perhaps not. I'm thinking of a model where the workspace has a scope and
revision selection rule. The scope says what resources the user of the
workspace is interested in (often collections), and the revision selection
rule specifies what revision of versioned resource in that scope will be
selected. So a workspace might rarely reference all resources available
from a particular server. It more of a means of selecting the resources a
client is working on at the moment, not all of which will be edited, so
this is not the same idea as an activity.
</jra>
- 11 Why can't a versioned collection contain a member denoting a
binding
to an unversioned resource? Its the collection that doesn't change, not
the
resource the collection member refers to.
This would mean that a workspace containing such a collection revision
cannot make a copy of that collection for use by the workspace, but
instead needs to have every workspace with that revision share a common
(mutable) unversioned resource. This removes the essential characteristic
that allows one to implement large numbers of workspaces working against
a common set of versioned resources.
<jra>
I don't completely understand. The server could copy the contents of the
versioned collection to cache the contents of a static workspace that
references it. In this case, the bindings to the collection members are
cached, and it doesn't seem to matter what they reference - versioned
resource or not, mutable or not, shared by other workspaces or not.
</jra>
Last paragraph should be removed.
Activities should be specified as part of checkin. So this section isn't
needed, advanced versioning doesn't add anything.
Needed to allow versioning aware clients to set up activity-based
workspaces for use by versioning unaware clients.
<jra>
This is a stretch. We're adding complexity to the protocol to support
versioning unaware clients to access functionality in advanced versioning?
This doesn't seem necessary.
</jra>
I agree that a conflict report should just "what a merge would do",
but I still think we need the report, since a user might want to find
out what the merge would do before requesting it.
<jra>
Agreed
</jra>
And Geoff, thanks for all your hard work too. I feel like I'm doing nothing
in comparison!