Re: Notes from 5/3/99 Versioning TeleConf
jamsden@us.ibm.com
Tue, 4 May 1999 10:26:24 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256767.004F8217.00@d54mta03.raleigh.ibm.com>
Date: Tue, 4 May 1999 10:26:24 -0400
Subject: Re: Notes from 5/3/99 Versioning TeleConf
"Geoffrey M. Clemm" <gclemm@tantalum.atria.com> on 05/03/99 04:39:58 PM
To: ietf-dav-versioning@w3.org
cc: (bcc: Jim Amsden/Raleigh/IBM)
Subject: Notes from 5/3/99 Versioning TeleConf
- Configurations
There was basic agreement with the proposed approach to configurations,
but the following issues were still outstanding:
Jim Amsden suggested that we replace the DAV:scope property with a
collection that is bound to the versioned-resources that would have
been listed in the DAV:scope property.
<jra>
What I was suggesting is that the collection members are what was listed in the
DAV:scope property.
</jra>
I personally think this is a good idea, because a binding is a more
stable locating mechanism than a URL. We would still need some property
containing a list of URL's to allow cross-server configurations (since
cross-server bindings are unlikely to be supported by many servers).
Jim further suggested that the configuration revision actually *be* this
collection.
I'm a little more hesitant about that, since I'm concerned that there
will be other "collections" that we will want to associate with a
configuration revision. I don't have anything particular in mind yet,
but I'm still concerned that something will turn up.
<jra>
I think we should be free to define whatever specializations of collection are
needed to provide the functions we want. Having a configuration be a kind of
collection isn't really a restriction, it just reuses collection semantics to
manage configuration members.
</jra>
We then discussed the "create a configuration revision without using
a workspace" issue. Chris indicated that the "configuration workspace"
described in the agenda makes sense, but is concerned that there are
complexities associated with introducing another flavor of workspace,
since we already have "checkout-token workspaces" and "version-selection
workspaces".
Jim Amsden suggested that we just allow a list of revisions to be
specified when creating the configuration revision. My concern with
this approach is that the server should confirm that the list of
revisions is a "legal" configuration (e.g. that it specifies at most
one revision of each versioned-resource, and that it selects a
revision of each internal member of a collection revision), and that
many servers will need a workspace to perform this computation efficiently.
<jra>
Yes, a server must support collection and configuration semantics when a member
is added to a configuration. These are:
- can't have the same member twice
- member must exist and specify either directly through a label, or indirectly
through a workspace an existing revision.
- adding a collection recursively adds all its members (subject to the same
rules)
- member must be an immutable revision. There is some question on this one.
These rules don't seem that hard to check incrementally on each edit to a
configuration. There is really nothing else a server can do in terms of
validating the consistency of the selected revisions. Only the client can know
through testing if the right revisions have been selected.
</jra>
An alternative approach is to let the client specify a label to be used
to pick revisions that should go into the configuration revision, but
this requires the client to actually put a label on all revisions to
go in the configuration, and requires the server to scan every
versioned-resource in the configuration to see what revision the
label would select.
<jra>
There's no choice if workspaces aren't available. Clearly configurations are a
more advanced concept in DAV versioning. But as has been pointed out a number of
times on the mailing list, simple versioning may be simple for the server, but
it won't be so simple for clients. Configurations may be very useful even in
servers that don't support workspaces or activities. They aren't just a revision
selector in a workspace revision selection rule, but may also be used:
- to query their members to see what revision made up a consistent set
- for deployment of a web application
- web publishing
- archiving
- site organization
I think of configurations as providing a "single version" view of a
multi-versioned space. This is what most users will want most of the time, even
if the server only supports simple versioning for creating the various
revisions. Those servers will likely require a publish step that copies specific
revisions to some other namespace for production access. Configurations
eliminate the need for this publish step.
</jra>
- Repositories
The next topic was a "repository" resource.
The purpose of a repository is to provide browse access to all the
versioning meta-data, such as versioned-resources, activities, and
workspaces. Although it is feasible to eventually locate most
information by following the graph of inter-object references, since
there are an infinite number of paths through this cyclic graph,
some mechanism that indexes the key resource types in an interoperable
way is very important.
The repository resource provides such a mechanism. In particular, the
repository is a collection which contains at least four standard
subcollections, named "activity", "versioned-resource",
"configuration", and "workspace". A member of the versioned-resource
or configuration collections would have a server-generated
versioned-resource-id as its name, while an activity or workspace
would have a client specified name.
<jra>
Configurations should not have server-generated names. These are user created
and controlled resources whose meaning is completely user defined. I don't see
the need for a repository to have a special mechanism for querying
configurations. A DASL search should be adequate.
</jra>
The repository also provides a convenient mechanism for naming versioning
metadata in a way that is accessible to non-versioning-aware clients.
The "property-collection" proposal was a way to avoid picking specific
names for these subcollections, but rather have the names of the subcollections
be specified as properties of the repository. Jeff McAffer suggested
that this level of naming flexibility is not needed, and the group agreed.
- Details for Upcoming Design Team Meeting
Dates: May 26-27
Sponsor: Rational Software
Location: Concord's Colonial Inn, Concord, MA
Phone: 978-369-9200
Room Rate: $125/night
Room Reservation Deadline: May 14, 1999
Nearest Major Airport: Boston Logan
Directions from Boston:
Sumner Tunnel
to Rte. 93N
to Rte. 95S exit
to Exit 29B (West Rte. 2)
follow signs for Concord Center
to Monument Sqare.
Note: The rooms at the Colonial Inn will probably disappear by May 15,
so reserving early is recommended.
Cheers,
Geoff