Next message: jamsden@us.ibm.com: "Re: Questions on activities"
Date: Tue, 11 Apr 2000 00:40:04 -0400 (EDT)
Message-Id: <200004110440.AAA10338@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Versioning TeleConf Agenda, 4/10/00 (Monday) 2-3pmEST
In the conference call, we spent most of the time going over the
points JimA raised in his recent "Re: Versioning 4.0 review"
message, so I'll use that message as an outline for the minutes.
From: jamsden@us.ibm.com
<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>
This appears to be a misunderstanding. "Reusing a workspace" was
intended to mean that a server could reuse a workspace after it was no
longer in use, because the working resource that previously was
identified by that workspace was deleted because of a CHECKIN or
UNCHECKOUT.
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>
Chris wanted to review the 04.2 proposal before commenting on whether
he wants this functionality in core versioning or not. My comment
here is that if a server is going to let you specify the working
resource id, it is likely that you can't just pick an arbitrary
string, but rather one that the server allows. You therefore need a
way to ask the server for a "legal" working resource id. I believe
the advanced versioning "make workspace" and "workspace" header pretty
much handle this. If such a server didn't want to also let you select
revisions in such a workspace, it would just refuse a
SET-DEFAULT-REVISION request that included a Workspace header.
But I don't think this needs to be required for core versioning.
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>
Jim proposed that "set RSR" and "update" are a better alternative.
Geoff believes that a simple versioning client will not want to
deal with an RSR and periodic "update" calls, but will want to
just say "I want this revision to appear by default" (in particular,
to all versioning-unaware clients). Jim still prefers "set RSR"
and "update" (to be continued :-)
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>
This topic didn't come up in the call today, but if I were JimW,
I'd probably say "English can be easy to confuse, and if we are
going to use some criterion for chosing terminology, avoiding
potential for confusion is an important one, more important than
using colloquial English". But speaking for myself, I don't care (:-).
- 10.5.1 Perhaps there should be a way to list all the members of
a workspace, not just the working resources.
My concern here is that a server might want to implement a
workspace by laying down a label on each revision that is to be
selected by that workspace. In that case, although the workspace
can always say what revision (if any) of a particular versioned
resource is selected by that workspace, it could not say what
all its members are (since it might have no way of enumerating all
the versioned resoures it has labeled).
And that's about as far as we got in the call.
Jim then ended by asking everyone to think through the use cases
and scenarios as they applied to these issues.
Geoff then asked everyone to read over the 04.2 draft.
And now for my response to the rest of Jim's response to my response
to his review of 4.0 (:-).
<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. </jra>
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>
The semantics of an unversioned resource is that a PUT to that
resource is seen by the next GET to that resource. This means that
two workspaces cannot have their own copies of that resource, but must
share a common resource. In contrast, each workspace can have its own
copy of a revision, since it is immutable.
<jra> DAV:current-activity 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>
It is essential that versioning unaware clients be able to author
resources on a versioning server (that's what DAV:auto-version is
all about). This is true for an advanced server that requires
an activity to be associated with each revision, but without
DAV:current-activity, a versioning unaware client would not be able
to author in an advanced workspace that requires activities.
Cheers,
Geoff