Next message: Geoffrey M. Clemm: "Re: Questions on activities"
Message-ID: <38FFDA51.EE22F28F@starmedia.net>
Date: Fri, 21 Apr 2000 00:34:26 -0400
From: Michelle Harris <michelle.harris@starmedia.net>
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
CC: ietf-dav-versioning@w3.org
Subject: Re: Questions on activities
Aye, please forgive my humble opinion on this matter as I am very new to WebDAV
and am only beginning to work with the most basic features. However, I am also
following the Versioning conversation so that I can fully understand it when the
time comes to implement that functionality. And the sections on Activities have
been the more taxing ones on my brain...I keep looking for a clear, explicit
explanation on how their envisioned use. If one exists, could you please point me
to the location?
With that said, I would like to say that I agree with the idea that more guidance
would be beneficial to advanced development on Versioning (especially
activities). Many developers are really only familiar with CVS and may have a
hard time abstracting out all the concepts necessary to successfully integrate
pre-existing version-control with WebDAV.
-Michelle Harris
"Geoffrey M. Clemm" wrote:
> 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