Next message: Jim Whitehead: "RE: Questions on activities"
Date: Thu, 30 Mar 2000 05:08:26 -0500 (EST)
Message-Id: <200003301008.FAA22927@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Questions on activities
From: jamsden@us.ibm.com
From Jim Whitehead:
Here's a couple of questions on activities in the -04 spec.
* From a design perspective, why are activities single resources,
instead of collections? An activity is essentially a collection of
revisions, but since an activity in the -04 spec. is just an
ordinary resource, to list the member revisions of an activity
requires asking for a specific property, instead of the membership
listing of a collection.
As near as I can tell, the reason we're using ordinary resources
for activities is one of simplicity. With an activity being just a
single resource, it's easy to act upon the entire activity, and it
avoids the question of how to handle operating on the members of an
activity-collection (especially since we're saying that a client
cannot directly modify the list of revisions in an activity).
<jra> An activity represents more than just a collection of
revisions, it include the notion of a particular line of descent of
those revisions. This would be hard to capture in a collection.
</jra>
An activity is a set of resources (i.e. revisions). I believe the main
thing that causes us not to model this as a collection is the fact that
there is no unique "name" associated with each member of this set
that would be suitable for use as the "binding-name" in a collection.
* Are activities versionable? The spec. makes it seem that it is
possible to create activities in version-controlled portions of the
URL namespace (i.e., the spec. does not require a client to create
an activity within the "DAV:activity-collection", defined on the
repository resource). If so, I imagine this could cause problems
if the current-activity of a workspace is not checked out (and
hence not writable), when a checkout is performed on that
workspace.
<jra> Activities are not versionable. I didn't think we had a
notion of version-controlled portions of the URL namespace other
than a versioned collection. Since (currently) a versioned
collection can't contain unversioned resources, the server would
return an error if the user attempted to create an activity in a
versioned collection. </jra>
I agree with JimA's answer.
* Who controls the namespace of activities, the client or the
server? Can a client give an activity any name it wants (assuming
it's legal according to URL syntax?) Or should we define the
MKRESOURCE method so that the server assigns activity names?
<jra> The client should control all namespaces. The server may
refuse requests it can't support. </jra>
I agree. Since it will be common for servers to require activities to
be created only in certain collections in the namespace, we agreed to
provide a REPORT that will enumerate these collections. But within
those constraints, the client can pick the name.
* What use scenario motivates the "DAV:activity-collection" (defined on an
activity)? The text describing it is somewhat contradictory:
Note: JimW is actually talking about DAV:needed-activities, not
DAV:activity-collection. To my knowledge, JimA is the only one
who has argued against the need for and value of a repository
resource (which he does so again below :-).
<jra>
The DAV:activity-collection is defined on a repository, not an activity.
The only motivations I can see for repository resources are:
1. a place to orgainize certain versioning meta-data types.
2. a way for versioning unaware clients to navigate versioning meta-data
The primary motivation for a repository resource is provided in the
versioning semantics section on repositories:
"Since a server will often allow certain metadata relationships to
be created only between resources in the same repository, it is
important to allow a client to specify in which repository a
resource should be created."
I'd have to see this concern addressed before I'd be willing to
drop the repository resource as an (optional) mechanism provided
by advanced versioning.
I disagree with both of these motivations. Workspaces, activities, and
configurations are user resources, just like any other resource, that are
created by users to enable some user-defined end result. I think users
should have complete control of the URL namespace and be able to organize
their resources in a way that best fits what they are trying to do, and
their unique processes. If they would find it convenient to place all
resources of a particular type in a particular collection, then this is
fine. If they decide to organize resources by the projects and functions
they are working on, this should be fine to. I don't see a need for an
interoperable way to locate resources of a particular type other than using
standard web crawlers and/or something like DASL. WebDAV should avoid
coupling concepts like namespace and resource type, even for resource types
it defines.
We have gone over this issue a lot. The reality is that many/most
versioning systems require that activities be created in a very
constrained namespace (i.e. in a collection defined by the server).
If we were defining a new versioning system that everyone was going to
implement from scratch, then I suppose we could try to provide the
namespace freedom that JimA advocates. But if we are going to provide
an interoperable protocol for accessing existing versioning systems,
we have to acknowledge the constraints of those systems.
Note: existing versioning systems have good reasons for constraining
the namespaces for versioning metadata, so even if we were defining a
new versioning system from scratch, I'd *still* insist on constraining
the activity namespace, but that's a separate topic.
On the second motivation, I find it difficult to imagine how a user unsing
a client that is not aware of versioning will muck around in the versioning
meta-data and do anything useful.
The point here is that a repository provides an alternative to special
versioning reports that can be requested only by versioning aware clients.
The repository effectively provides the "stable URL" that allows a
versioning unaware client to be used to look at the history of a
versioned resource. This is not the primary motivation for the
repository object, so I'm happy to stipulate that this alone would
not be sufficient to motivate the existence of a repository resource.
The versioning methods are designed to
manipulate this meta-data based on the semantics and maintain its
integrity. If non-versioning aware clients are allowed to access and
manipulate this meta-data manually, it would be confusing for read-only
operations, and a potential disaster for updates.
Most versioning metadata properties are read-only (i.e. defined as
being "protected" in the protocol), and this would be enforced by
any reasonable implementation. The writeable properties (such as DAV:author
and DAV:comment) could reasonably be updated by versioning unaware
clients. So I see no potential disaster for updates.
I'm not sure what "it would be confusing for read-only operations"
is referring to.
Second, I think it is
unnecessary for all current applications, like say Microsoft Office2000, to
become versioning aware in order to use WebDAV versioning. There will be
WebDAV explorers that are versioning aware and can invoke non-versioning
aware applications on revisions. The explorer client can handle all the
versioning needs of many other non-versioning, and perhaps even non-WebDAV
client applications. So I don't think it is necessary to provide a lot of
down-level client versioning capabilities.
</jra>
I agree that we have explicitly designed the versioning protocol to
be useful for versioning unaware clients. One way we have done so is
by making the versioning metadata available in the form of properties.
When those properties contain stable URL's, that gives a versioning
unaware client access to the versioning metadata (e.g. the predecessor
of a revision). The repository resource provides the location
for those stable URL's.
But now we get back to JimW's question (which as JimA points out,
is about the DAV:needed-activity-set, not about DAV:activity-collection).
I thought the whole point of an activity was to capture one whole logical
change. Why are activities all of a sudden incapable of recording entire
logical changes?
<jra> This is refering to the DAV:needed-activity-set of an
activity, not the DAV:activity-collection of a repository. It is
often the case that a functions and changes are dependent on other
functions and changes. The DAV:needed-activity-set is used to
identify other change sets that could stand alone, but are required
by this activity for completness. For example, consider a new
function that depends on a bug fix in some other function. The bug
fix is a separate activity that represents a complete unit of work
in itself that can be released to solve a customer problem. Now the
new function can't work without the bug fix. Creating new function
certainly isn't the in the same unit of work as the bug fix as this
would imply that the customer would get the new function along with
the bug fix. So the new function is in a new activity. But there is
still that dependency which is captured in the
DAV:needed-activity-set. </jra>
I agree with JimA's answer.
"The purpose of this property is to identify other activities that
are a prerequisite to this activity."
Prerequisite in what sense? I'm guessing that this property is
intended to record *dependencies* between activities. If this is
true, then who is responsible for maintaining this property (client
or server?)
<jra> The prerequisite is really just the dependency as you
described. The client is responsible for setting the dependency,
the server is responsible for remembering what was set, and
including the resources in the dependent activity in the revision
selection scope of the referencing activity. </jra>
I agree with JimA here as well.
Cheers,
Geoff