Next message: Geoffrey M. Clemm: "Re: Questions on activities"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568B2.0029CA23.00@d54mta03.raleigh.ibm.com>
Date: Wed, 29 Mar 2000 19:05:23 -0500
Subject: Re: Questions on activities
Comments in <jra> tags below.
|--------+---------------------------------->
| | Jim Whitehead |
| | <ejw@ics.uci.edu> |
| | Sent by: |
| | ietf-dav-versioning-requ|
| | est@w3.org |
| | |
| | |
| | 03/27/2000 05:50 PM |
| | |
|--------+---------------------------------->
>----------------------------------------------------------------|
| |
| To: ietf-dav-versioning@w3.org |
| cc: |
| Subject: Questions on activities |
>----------------------------------------------------------------|
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>
* 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>
* 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>
* What use scenario motivates the "DAV:activity-collection" (defined on an
activity)? The text describing it is somewhat contradictory:
<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
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.
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 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. 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>
"This property identifies the other activities that form a part of the
logical change being captured by this activity."
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?
"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>
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.
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>
- Jim