Next message: jamsden@us.ibm.com: "versioning-04 review"
From: Jim Whitehead <ejw@ics.uci.edu>
To: ietf-dav-versioning@w3.org
Date: Mon, 27 Mar 2000 14:50:12 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJIEJIDAAA.ejw@ics.uci.edu>
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).
* 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.
* 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?
* What use scenario motivates the "DAV:activity-collection" (defined on an
activity)? The text describing it is somewhat contradictory:
"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?)
- Jim