Next message: jamsden@us.ibm.com: "RE: Questions on activities"
From: Jim Whitehead <ejw@ics.uci.edu>
To: ietf-dav-versioning@w3.org
Date: Thu, 30 Mar 2000 10:31:47 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJMEMPDAAA.ejw@ics.uci.edu>
Subject: RE: Questions on activities
Jim Amsden writes:
> <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>
Hmm, but right now I don't think the activity records a line of descent
(except by recording multiple revisions within a single versioned resource,
but there doesn't appear to be any constraint that the revisions need to be
on the same branch).
> 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.
Actually, each revision does have a unique URL associated with it, thus
implying that this drawback already needs to be handled, right? (Note that
I'm not really arguing for using collections, I'm just trying to get the
rationale for using a non-collection resource down crisply).
> <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.
I concur as well.
> * 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.
OK, if the client chooses the name, this could lead to namespace collisions.
How can a client be guaranteed of selecting a unique name without having to
retrieve a listing of all the names of all the activities? Especially if
the activities are kept as a flat list in a single collection, this listing
could have hundreds or thousands of entries. Trial and error doesn't seem
right either. What if two clients decide to use the naming scheme
"activity{activity #}", as in "activity0001", "activity0002", etc. Then if
a new client comes along, it'll try "activity0001" --> nope, already taken.
OK, try "activity0002" --> nope, sorry again, keep trying. For a large
number of activities, 1,000 (or insert your favorite large number here)
requests later it'll say, "OK, here you go, you finally picked a free name".
Or, the client could simply say, "dear server, please assign me a unique
name following your naming conventions". 1 request, 1 response, much more
predictable behavior.
> * 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.
D'oh! You're absolutely right, I typed the wrong property name.
> 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>
OK, having the rationale for DAV:needed-activities be the recording of
dependent activities makes sense. But, it seems to me that this could
potentially get us into trouble. I think there is a lot of policy that
surrounds the successful use of this property, and we need to provide some
guidance on how to use it. For example, the tendency is for this activity
to grow without bounds, since over time every new change will be dependent
on a large number of other changes. There needs to be some way to take a
snapshot and say that, as of this snapshot, all dependencies have been
accounted for. After the snapshot, the dependency tree can start being built
again. Without this occasional clearing away of the prior dependencies, it
seems to me the revision selection rules would grow larger and larger, and
servers would be less efficient at evaluating the continually growing
revision selection rules.
- Jim