Re: WeDAV Versioning Summary
Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Fri, 16 Apr 1999 23:59:27 -0400
Date: Fri, 16 Apr 1999 23:59:27 -0400
Message-Id: <9904170359.AA23444@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: jamsden@us.ibm.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <85256756.0000DF62.00@d54mta03.raleigh.ibm.com>
Subject: Re: WeDAV Versioning Summary
From: jamsden@us.ibm.com
See <jra> below. Geoff, you didn't have any issues with the section on
locking?
Ooops. Yes, I did, but just noticed I forgot to mention them, thanks for
the reminder! I'll add them below.
...
Perhaps "creates an initial revision that is a copy of that resource".
<jra>
I changed it to "creates a versioned resource and converts the resource
into the initial revision". I didn't want to use copy because that would
imply a WebDAV copy which would mean the original resource somehow still
exists.
Good point. I agree that your rewording is better.
There is a distinguished, floating label called "latest" which
always refers to the latest revision in a given activity.
The default semantics of adding an activity to an RSR is "latest in
the activity", so there is no need for a "latest" label. In addition,
when there are multiple parallel activities adding revisions to a
versioned resource, it would be ambiguous which one "latest" referred to.
<jra>
By "latest" I mean latest in time regardles of activity. I agree this has
limited usefulness. Using some "mainline" activity (like DSEE) would
probably be better. I had included it for servers that don't implement
activities. Is this OK?
I'd rather just have "latest" be a revision-selection-rule element,
rather than requiring that there actually be a label named "latest".
And when describing the semantics of this rsr element, you wouldn't
want to use the phrase "in a given activity",
since this is latest across all revisions, not latest in a given activity.
Your wording in the subsequent "revision selection rule" section is
just fine though.
A revision of a collection is modified by adding or removing member
URLs.
Using the new "bind" semantics, "by adding and removing bindings to
other versioned resources".
<jra>
Should be bindings to other revisions not versioned resources? I'd like to
leave this description pretty generic where the "members" of the
configuration are somehow revisions identified by some means.
The term "member" has very specific semantics in the base WebDAV protocol,
so we probably shouldn't use it to refer to some more generic concept.
But I agree with your underlying point ... this is not a standard kind
of binding, but rather a "versioning binding"
which has the property that it is a binding to a versioned resource but
that operations on that versioning binding are applied to the working
resource or revision selected by the workspace for that working resource.
Then we can
cover the details in the model and protocol after bind/reference issues are
resolved. OK?
</jra>
That makes sense, but lets use a different term than "member", to avoid
confusion with the technical meaning of member as defined by WebDAV.
How about "versioning reference" or "versioning binding" ?
Probably worth noting here that "latest" is just based on modification
time,
and is independent of the predecessor/successor relations created by
checkin/checkout.
<jra>
Done. See comments above about latest too. This looks like you agree with
those concepts.
Yes, definitely.
I'd say "a default activity", rather than "the null activity".
"Alternatively, the default workspace can contain the current-label
"default", and with label=default in the version selection rule".
<jra>
Actually, the workspace could contain both. They're not mutually exclusive.
I'd prefer to just have one or the other, to keep the label-based approach
distinct from the activity-based approach, but I agree that you logically
could have both.
<jra>
The default activity isn't the same as the null activity. Instead I sould
have said no activity. I'm not sure there is a default activity anymore. Is
there?
No, so I agree that "no activity" would have been better.
But I'd require that one have either a current activity or a
current label in order to do a checkout/checkin.
The server is allowed to use an existing workspace instead of creating a
new workspace, so this should probably be "the server allocates a workspace
for the checkout, possibly reusing an existing one, and returns this
workspace
as a `checkout token' for use by the client to identify the working
resource."
<jra>
I dont' think this is the case. Only users can reuse workspaces (tokens or
not) because reusing a workspace implies being able to see working
revisions checked out in that workspace. You wouldn't want a server
automatically making someone else's checkouts visible to you.
</jra>
I believe this *must* be the case to achieve interoperability between
a "token-based" client and a "workspace-based" server. A workspace on
a workspace-based server is far too expensive for it to have to create
a new one on every checkout. Since a token-based client will only use
that "workspace" to access the single URL that it checked-out, this
shouldn't be a problem. Also, the "lock" that a token-based client
will commonly put on the working resource will ensure that the working
resource is not modified by another client. So the fact that other
clients may have checkouts in that workspace would not be a problem.
I'd avoid the word "contain" here, since I still believe we do not want to
model configurations as collections, but rather as "opaque resources" that
can be placed in a workspace to recover a saved configuration. This allows
far greater flexibility in implementation by the server. But that is
a topic of current discussion (:-).
<jra>
The words member and contain are intended to be generic and have their
usual semantic meaning rather than implying a configuration is a kind of
collection or not. Whether we make this distinction depends on whether or
not we need to inherit collection semantics for configurations. One way to
do this is to have the configuration members simply be URLs that are
references to revisions of versioned resources. However, this is not the
only way a configuration could be implemented. So I'm not that stuck on if
its a collection or not. Its just nice to reuse concepts where possible as
it is a good indication the original concept was useful.
</jra>
I'm concerned that if we say a "member", readers will assume that we are
using the formal WebDAV meaning of the term. Probably "contain" is fine,
since I don't believe that is a formally defined term in the base WebDAV spec.
Locking Versioned Resources
Locking a versioned resource prevents any revision from being checked
out in any activity.
That's fine.
Locking a revision of a versioned resource
prevents just that revision from being checked out in any
activity.
I don't think that is right. A lock is a combination of locking
the state of a resource, and locking the identification of the URL
with that resource. Locking the state of an immutable revision is
redundant, since this is guaranteed by its being immutable. Locking
the state of a mutable revision is a reasonable thing to do, so
that's worth mentioning.
Having the "single-checkout" property on a revision makes sense.
This ensures that if you checkout that revision, nobody else can.
But I see no important use case that is addressed by having a
"nobody can check out this revision" semantics for a lock, and
I see the bad effects of someone locking a resource (e.g. to prevent
change to a mutable revision), and thereby mistakenly preventing
any work to be done based on that revision.
Locking an activity prevents any revisions from being
checked out in that activity.
Good.
Locking a workspace prevents any
checkouts in the current activity of that workspace (similar to
locking the current activity), and prevents changes to the workspace
revision selection rule.
I wouldn't add the "prevents checkouts in the current activity" clause.
The client can explicitly lock that activity if they want to, but shouldn't
be forced to just because they wanted to lock the RSR.
Cheers,
Geoff