Re: Version issues
Jim Whitehead (ejw@ics.uci.edu)
Thu, 1 Apr 1999 16:57:49 -0800
From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Thu, 1 Apr 1999 16:57:49 -0800
Message-ID: <003601be7ca3$d43af660$d115c380@ics.uci.edu>
Subject: Re: Version issues
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Friday, February 19, 1999 11:27 AM
To: Chris Kaler
Cc: jamsden@us.ibm.com; gclemm@atria.com; ejw@ics.uci.edu;
dgd@cs.bu.edu; Cragun.Bruce@gw.novell.com;
sridhar.iyengar@mv.unisys.com; ckaler@microsoft.com;
bradley_sergeant@intersolv.com; ABabich@filenet.com
Subject: RE: Version issues
Chris,
We're getting closer! See <jra> tags below.
Chris Kaler <ckaler@microsoft.com> on 02/19/99 12:58:02 PM
To: Jim Amsden/Raleigh/IBM
cc: "'gclemm@atria.com'" <gclemm@atria.com>, "'ejw@ics.uci.edu'"
<ejw@ics.uci.edu>, "'dgd@cs.bu.edu'" <dgd@cs.bu.edu>,
"'Cragun.Bruce@gw.novell.com'" <Cragun.Bruce@gw.novell.com>,
"'bradley_sergeant@intersolv.com'" <bradley_sergeant@intersolv.com>
Subject: RE: Version issues
Sorry about the formatting -- my mail program at home seems to do that.
I cut the long legacy of mail exchanges :-)
Some comments below...
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Friday, February 19, 1999 9:01 AM
To: Chris Kaler
Subject: RE: Version issues
Chris,
As you can see, the formatting got a little messed up. A couple of points
that must be made clear:
1. Everyone sharing the same view does not work on the Web. Recall this is
distributed authoring. It must provide the openness, ease of use, and
flexibility that is characteristic of the web, not localized development
shops.
[CK] OK... I'm not sure I understand your point here. Although, this
is WebDAV, "web distributed authoring..."
<jra>
What I'm saying is that what works for a local, integrated development
organizations working on a product or two isn't distributed authoring on
the web. It is much more likely that different users will require different
views of the revision space when versioning is scaled to the web.
</jra>
2. First, WebDAV will be a new paradigm for clients. We're not trying to
reproduce what everyone already has, we're trying to develop a standard
protocol for distributed authoring. This will require compromises and
hopefully minor paradigm shifts in order to interoperate with existing
systems. However, existing systems and paradigms should not arbitrarily
constrain WebDAV or we limit our ability to progress. Second, workspaces in
level 1 do not require clients who don't want to use them to do anything.
If all you ever want is checkedout and latest, and you want all users to
share the same view, put checkedout and latest in the default workspace.
There's nothing else that needs to be done. Workspaces don't prevent your
simple semantics, they just provide flexibility for more scaleable
semantics in a simple way.
[CK] My point is that today we have people doing what we are
trying to standardize. The products work and scale just fine.
Adding in complexity will slow adoption
rates. My real issue here is that if I look at products today
that I would consider "level 1", the workspace notion, as I understand
it, doesn't meet all of their needs, and adds complexity with no
perceived value. So why would they want to use it. I'm taking
an extreme position here to illustrate my point, clearly I understand
the benefits of DAV and standard protocols, ... One example is
that I need to be able to checkout any revision, not just the tip
and I should have to use workspaces to do that.
<jra>
I don't see workspaces adding complexity, in fact I seem them removing it.
Again, what needs do existing "level 1" clients have that workspaces don't
fit? Please quantify the complexity with concrete examples. I think I have
given a number of examples where workspaces in level 1 do have preceived
value.
</jra>
3. Using workspaces does not mean you can't access a particular revision
with a label. This is in both the goals and the model. Geoff didn't want
access by labels, but I have convinced him that this is necessary. For
example, say your workspace picks revision R3. You might want to take a
quick look at R2 or run a diff program against both. The model specifies
that it is possible to specify a URL and workspace, a URL and label, or
simply a URL to access a versioned resource. URL+workspace gives the
revision selected by the revision selection rule of the workspace.
URL+label overrides the workspace and gives the labeled revision. URL alone
is resolved in the context of the default workspace. I think this covers
all you cases below.
[CK] What about URL + revision-id? As well, it is more than just GET.
How about PUT? How about CHECKOUT? I think this is where I am
getting hung up. The goals talk about labels and get operations
and then use workspaces and activities for parallel and non-tip
checkouts.
<jra>
Yes, I think this is the hangup. I didn't mean label, I meant revision
name. It includes labels and the revision id, and it works on any method.
All methods take a target URL. When versioning is added, all methods have
additional headers for the workspace or label, with the default workspace
selecting the revision when no workspace or label is given.
</jra>
What this means is that a simple level 1 client/server could use a default
workspace with checkedout, mainline, and latest in the revision selection
rule. In this case, "mainline" is effectively the single activity that all
changes are made in, no parallel development. Then users could follow the
paradigm you suggest by getting anything they've checked out, or the latest
revision if they only specify a URL. The activity has no effect in this
case because there is only one. So latest is always latest in the mainline
activity. Then if a user wants to see some other revision, he can use the
URL and a label. If an administrator wants to change the revision all users
see by default, he can change the revision selection rule in the default
workspace. The clients never need to know this happened. They'll just start
seeing the corrected revisions. Finally, if a client does want to see their
own view of the revisions, they can create their own workspace, set the
revision selection rule as they wish, and then not be effected by other
users.
[CK] This is great, but I still have a couple problems with it. It
doesn't support parallel development for level 1 clients, and
updating the RSR feels to complex. For the latter, maybe I'm
just stuck at the protocol. You are saying "change the RSR" and
I'm saying, "I'd like a method to help me change the RSR". So,
I think we are saying the same thing on that point.
<jra>
We said level 1 clients don't have parallel development. That's level 2.
Again, just allowing branches doesn't support parallel development. You
have to be able to do something with those branches after you create them.
How is updating an RSR complex? Workspace could have methods to add and
remove entries to/from the RSR. The current model just uses an XML document
fragment, just like PROPFIND and PROPPATCH, but we could add some
convenience methods to the model and/or protocol. Updating an RSR will
usually be just adding or removing a label and/or configuration (for level
2). Why do you think this is complex?
</jra>
I think this provides your semantics, is simple, defines level 1 semantics
in terms of level 2 constructs, provides saleability where needed but
simplicity where it isn't, does not introduce different mechanisms for
defaulting in level 1 and 2, and provides client flexibility.
[CK] I'm right there with you, if we can have parallel checkouts
and non-tip checkouts for level 1 clients.
<jra>
I'm still looking for that use case from you describing this requirement.
</jra>
Note that level 1 servers are not required to support any activity
including the default mainline activity. They only need to behave as if
such an activity did exist. For a single activity, this doesn't mean very
much, its just a way of specifying semantics.
[CK] Agreed.