- From: Andre van der Hoek <andre@bigtime.cs.colorado.edu>
- Date: Tue, 17 Dec 1996 15:40:20 -0700
- To: w3c-dist-auth@w3.org
Precursor commentary:
1. This is a long, long, posting, excuses, but I think it is
needed.
2. This posting presents a separate research project that seems
to deal with many of the same issues that WEBDAV is dealing
with, and as such seems to have tremendous relevance.
3. Jim asked me to post this, disclaimers to him....., but we
definitely would like to be involved in hashing out the issues
addressed below.
Here we go:
WEBDAV group,
over the past year, our research group has been developing an interface
that is similar to the interface the WEBDAV group is developing. Our
goal was to come up with a versioning interface that was generic enough
to model various versioning policies (for example, check-in/check-out
such as in RCS, branch and merge such as in CVS, etc). A pointer to
this work (NUCM) can be found at the WEBDAV webpage maintained by Jim.
It should be noted that our work is not specific to any implementation,
but simply specifies an interface.
As I understand it, the WEBDAV group is developing an interface for
versioning on the WWW that is also policy-neutral. No surprise there,
Jim and I have been buddies for a while now. Anyways, only recently I
got a chance to read up on the WEBDAV work and compare it with our
current efforts. I noted one of the main decisions was that the group
would concentrate on versions only at first, and then move on to
incorporate the notion of configurations lateron. However, when I
carefully read the specs (both the one by the Netscape people and the
one by Jim and Yaron), I can't help but notice that most of the needed
structure for support for versions *and* configurations is already
there. Important to this is that access, locks, attributes, and
versions are orthogonal in both models:
access -- GET
locks -- LOCK/UNLOCK
attributes -- ATTRIBUTE SHEETS, ATTRIBUTE HEADERS
versions -- CHECKIN/CHECKOUT
These primitives pretty much work separate, and mostly do not need
each other to successfully complete. However, the separation is not
quite clean yet. To me, having gone to a similar effort, the danger
now in just dealing with versions and not dealing with configurations
is that the spec now can prescribe something that will be completely
valid and logical to versions, but lateron will cause a slightly
different treatment of configurations. In our approach, this is
exactly what happened, even though we tried to unify both in our first
attempt, we did not succeed; and only very recently we have been able
to redefine the interface and straighten out the differences.
My point: I believe the working group should pay attention to
configurations, and hash out the issues now rather than later,
especially since most of the support is already in place.
Below I will show our current interface, that we believe deals cleanly
and simply with both versions and configurations, in the hope that
the WEBDAV group can take advantage of this work, and not make the
same mistakes we made the first time around.
First though some preliminary comments about our work:
1. NUCM takes a similar approach as WEBDAV: everything is as
orthogonal as possible, i.e., access, versioning, locking, etc
all are separate.
2. It assumes a server + workspace type of approach. Clients
contact the server to get certain operations done; however,
some of the work can be done by the client itself without
the need to contact the server.
3. NUCM could very well be used in an implementation of the WEBDAV
spec, i.e., our implementation could very easily be hooked up
to an existing Web server to provide versioning. The Web
server simply translates the WEBDAV requests to NUCM (our work)
requests. Even better, if we can develop a one-to-one mapping,
this translation would not be needed.
Anyway, there is the interface (somewhat annotated). First some
definitions that will be used later:
artifact -> an atom or a collection
atom -> something that does not have structure to the
versioning model, only versions of this artifact
make sense to the versioning model
collection -> a container, or for that matter a configuration.
basically groups atoms and collections. The
grouping points to individual versions of its
members.
All artifacts can be versioned, and our versioning model simply
assumes a directed graph type of structure (no cycles allowed though).
To address artifacts, we have two ways:
target -> has to be resolved to something in the workspace
(in WEBDAV terms: an artifact at the client site,
that has been retrieved with a GET).
For example: /bla/bli/foo.bar
path -> an artifact that directly points to something in
the complete versioning space.
For example: //bla:6/bli:3/foo.bar:7
The workspace typically is a slice through the complete versioning
space, hence no version numbers needed in specifying a target, a
simple path is usually enough.
The first set of primitives deals with *access* to the complete
versioning space that resides at the server. The following primitives
exist (annotates: R -> recursive, D: has to go to versioning space
to do something, L -> can be done in local workspace):
open(path, prefix-target) D
close(target) R L
list(path) L
iscollection(path) L
The most important one is "open": it opens a particular path on a
particular artifact and brings this artifact to the client site. For
example:
open("//bla/bli:4/foo.bar:7", some-directory-here)
puts the foo.bar version 7, that is a member of bli version 4, that
is a member of the current/latest version of bla, in the directory
specified. Open works for both atoms and collection, in case an
atom is opened, the file is transported to the client site. In case
a collection is opened, at the client site a directory is created
mimicing this collection, and in the directory some meta-information
about the collection is maintained (such as a list of its members).
However, the members themselves are *not* retrieved; as opposed to
WEBDAV where this currently is the case. It is our believe that
retrieving members would be bad, because recursively this could lead
to a large retrieve operation; even if done only for the current
directory this could be a large operation. Assume 10 executables
of 1 meg each are in the directory and the user is interested in
the header file that is 1K, this scheme is much better in this case.
"close" removes (recursively) the target specified from the workspace;
only if no members are currently checked-out; our model forces one to
either abort or commit the changes before allowing a close.
"list" lists the members of a collection.
"iscollection" checks whether the specified path denotes an atom or
a collection.
To manipulate atoms, one would use vi, emacs, or whatever favorite
editor one would like to use. For collections, NUCM's interface
specifies a limited set of operations that they support (these
operations are only allowed when initiatechange has been used on
the collection beforehand, see below):
add(new-target) D
remove(target) R L
rename(target, new-name) L
import(path, new-target) D
replace(target, path) R D
"add": the user has created a new artifact, and would like this to
be added to the collection, the collection is implicitly defined by
the place where the user created the artifact. This function is
not in the current WEBDAV spec.
"remove": obvious, removes an artifact from the collection. The
current WEBDAV delete/destroy can be enhanced to do this.
"rename": obvious, allows an artifact to be renamed in the current
collection. WEBDAV allows this.
"import": very important function. To share the history of an artifact
across multiple collections, one needs to have the capability to
import an artifact from somewhere in the versioning space in the
current collection; import does this. Basically an "add" of an
existing artifact as opposed to a new artifact. WEBDAV does not
support this at this moment, and hence can only make a copy of an
artifact and then lose its shared versioning history once modifications
are made to both artifacts.
"replace": replaces an existing artifact with another artifact in the
versioning space. This can either simply be a replacement of a version
(i.e., this collection should point to version x instead of y of this
artifact), but can possibly replace an existing artifact in the
collection with any other artifact from the versioning space.
Basically replace is a "remove" followed by an "import".
This limited set of functions has all the capabilities needed to
manipulate collections at will.
Now for the tricky part: versioning. Versioning functions are
completely orthogonal to the access functions: once something is
"open", the functions below become available. Opened artifacts
typically are readonly, the functions below are used to get permission
to manipulate the artifacts and to store the new versions of the
various artifacts. The functions below do not care whether the
artifact is an atom or collection, that is taken care of by the
functions above (rename, replace, add, import). The WEBDAV work
could and in our opinion should take a similar approach....
initiatechange(target) L
abortchange(target) L
commitchange(target) D
commitchangeandreplaceold(target) D
version(path) L
isinitiated(target) L
lastversion(path) D
existsversion(path) D
"initiatechange", same as "check-out". However, does not have
a lock attached to it at all. Simply announces that this artifact
might chance lateron, and then allows the user to edit the artifact
(chmod +w for an atom, for collections enables the functions add,
import, etc).
"abortchange", same as "uncheck-out". Says: abort this change,
and return artifact to previous state. Could not find this in
current WEBDAV, should be there I believe.
"commitchange", takes all the changes made to an artifact (i.e.,
the edits of an atom., or the new membership list of a collection),
and creates a new version in the versioning workspace with the
new contents. This does not automatically link this new version to
its parent collection (if it belongs to a parent collection), the
"replace" should be used for this. Also, this function brings the
atom back to a state in which it can not be changed. This basically
is the "check-in" in WEBDAV.
"commitchangeandreplace", same as commitchange, but replaces the
version that was worked on with the new version, i.e., no new
version is created.
the other functions are simply information retrieval functions.
Notice one more time: no locks associated with this interface,
and the functions work on both atoms and collections.
Some garbage collection primitives:
destroy(path) D
User can explicitly destroy a specific version of an artifact
using the "destroy" function. Most of the garbage collection can
take place automatically though, as artifacts that are not a member
of any collection can simply be removed by the server (they are
not reachable anymore).
We have taken the approach of locks being completely separate from
versioning, and have generalized its approach. Basically, arbitrary
attributes can be set and changed with the following primitives:
testandsetattribute(path, attribute, value) D
getattributevalue(path, attribute) D
removeattribute(path, attribute) D
"testandsetattribute" first tests whether an attribute is set, if so,
returns that it can not set the attribute, otherwise sets the attribute.
The other two functions have the obvious semantics. The value of an
attribute then can contain basically anything, such as "lock set by
XXX, expires YYY", or "comments to this version", or whatever.
WEBDAV currently separates out locking and attributes, and given its
situation that might be good; however, a more generic approach could
be applicable.
The following primitives are used to provide distribution in our
interface; for WEBDAV currently probably not relevant.....
mount(remote-path, new-target) D
getlocation(path) D
export(path, remote-site, permissions) D
revokeexport(path, remote-site) D
move(path) D
Now for the conclusion. Looking at the current state of WEBDAV,
I see a lot of the above functionality trickle in: "we need COPY,
MOVE, DELETE", and also already a "MKDIR" in some places. However,
the addition of these are still on an ad-hoc basis, and we believe
the above example interface is consistent from the ground up, and
we strongly recommend WEBDAV to take a look at the functions,
realize that most of what is needed is already there in WEBDAV.
Hopefully the above presentation can help WEBDAV to include
configurations in the current spec, and thus unify its approach
to both versions and configurations.
Notice also that even though our approach is based on workspaces,
this does not limit its applicability. First of all, if in future
clients are versioning aware, some of the functionality (mostly the
"L" annotated functions above) can all be taken care of at the client
site, without the need to contact a server. However, even when
clients are not aware of versioning, a server can simply set up the
workspace at its site, and filter the information through there to
the client without much extra cost.
I hope this helps to resolve some of the WEBDAV issues, any comments
on the above opinions are welcome, and I would be happy to throw in
any additional explanations that might be needed.
Greetings,
=== Andre ===
--
=====================================================================
= =
= Andre van der Hoek. =
= E-mail: andre@cs.colorado.edu University of Colorado at Boulder =
= Phone : 303-492-4463 Dept. of Computer Science =
= Fax : 303-492-2844 P.O. Box 430 Boulder, CO 80309 =
= WWW : http://www.cs.colorado.edu/users/andre =
= =
= Somebody has to be brilliant, but it ain't me, although I hoped so. =
= =
=====================================================================
Received on Tuesday, 17 December 1996 17:40:24 UTC