Next message: Michelle Harris: "Re: Questions on activities"
Date: Fri, 21 Apr 2000 00:06:12 -0400 (EDT)
Message-Id: <200004210406.AAA25161@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Questions on activities
From: Jim Whitehead <ejw@ics.uci.edu>
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.
> I think you make a very good point. Any suggestions on how to
> marshal this kind of request?
I think the MK* method could be submitted to the enclosing
collection, and the semantics of the method would be to generate a
new unique name, and in the response return the name that was
selected.
That's OK with me. Anyone object? I believe this applies only to
activities, of which there is an ever increasing number. I believe
workspaces should have a client requested name, since old workspaces
will be cleaned up periodically.
having the rationale for DAV:needed-activity-set 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.
I haven't seen this happen in practice. A given change is usually
applied to a particular workspace, with no specific other activity
that it depends on.
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.
I don't think users will be building many dependency trees. Every so
often they might say "you need this activity in order to use this other
one", but that's about it.
my concern here is twofold:
a) complicated features in WebDAV that aren't anywhere even as complex as
this (e.g., shared locking, writing properties) haven't been used, and I
think one reason is that not enough guidance was provided. Without any
guidance on how clients should make use of this feature, I don't think it
will be used at all.
I don't see that the DAV:needed-activity-set is complex. The only
semantics are that if you MERGE an activity, the MERGE is also applied
to all the DAV:needed-activity-set of the activity.
b) If clients do end up using the feature, I'm concerned they might choose
mutually contradictory (or perhaps just merely interfering) policies on its
use.
I've never seen this problem arise in activity-based systems, so I
guess don't share your concern. Has anyone ever experienced this kind
of activity dependency bloat in a versioning system?
Cheers,
Geoff