Re: configurations and all that...
Jeff McAffer OTT (Jeff_McAffer@oti.com)
Wed, 07 Apr 1999 18:28:24 -0400
From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
To: gclemm@tantalum.atria.com (Geoffrey M. Clemm)
Cc: ietf-dav-versioning@w3.org (ietf-dav-versioning)
Message-ID: <1999Apr07.182400.1250.1138379@otismtp.ott.oti.com>
Date: Wed, 07 Apr 1999 18:28:24 -0400
Subject: RE: configurations and all that...
[... snip ...]
> I get the feeling that while we acknowledge that
> configurations are not necessarily "the entire world" of
> immutable
> resources, people think of them as workspace things and
> assume they are
> relatively rare. Certainly it is assumed there are few of
> them in the
> RSRs.
>
> Those are two very separate statements. Some of us believe
> that configuration
> revisions will be created frequently (i.e. possibly several
> per day per
> client). So it becomes critical that a configuration
> revision be amenable
> to very efficient implementation. But you only need one of
> these "historical"
> configuration revisions in your RSR at any one time (just as
> your workspace
> selects a single revision of a versioned-resource at any one
> time). So you
> can have lots of configuration-revisions while only having a
> few of them in
> your RSR at any one time.
In principle I agree with you with and note that "frequent" for us is
several revisions of hundreds of "components" per day depending on the
phase of the project. I agree that individual users only need one
revision of each of these components in their RSRs at any one time.
Frequency is somewhat orthogonal to granularity.
> The workspace is the view onto, or context for, the
> resources (i.e., specs revisions via RSRs) but that's it.
>
> Although that is a pretty important "it" (:-). In
> particular, although
> a workspace with no resources displayed in it is pretty useless, a
> mass of versioned resource revisions is also pretty useless,
> unless you select an interesting slice through them (which is what a
> workspace does).
I don't mean to trivialize workspaces either in complexity or usefulness.
My point was simply that workspaces are disposable, resources are not.
Users are mostly interested in managing and persisting resources.
> This is, I
> believe, the operation everyone has been talking about and
> calling
> "snapshot the workspace within some scope"?
>
> Not quite. There is the contingent that wants to just talk about a
> set of revisions, independent of their membership in any collection.
> All contingents agree that there must be some mechanism that selects
> which revision of a versioned-resource that goes into the
> configuration,
> and that "what is currently in the workspace" is one such mechanism.
> The disagreement occurs on whether it is the only mechanism.
Hmmm, good point. Is there, at some level, a "collection" which
represents/indicates the set of interesting resources, for these users?
At the very least this might be the "scope" for the snapshot operation?
> Thought: Is "snapshot" = "checkin a collection with depth
> infinity"?
> The collection you check-in is the scope (references the roots
> of the collections of interest). The deep check-in updates the
> collection to contain all the mappings...
>
> That's how I look at it, although I would have said "The deep check-in
> creates a configuration-revision that contains all the mappings".
works for me.
> Question: How do I ship a component to someone and retain
> revision info
> etc.?
>
> I assume by "shipping a component", you mean "shipping them all the
> revisions in a particular configuration revision of that
> component". In this
> case, it is sufficient to ship the URL of that configuration revision.
No. I actually mean, gather up all the bits and bytes that constitute
all the revisions of the resources in a set of configurations and send
them to someone else who will put them in their compatible webdav server.
We really want this to support distributed teams working on the
same/related sets of resources but who are unable to share webdav
servers. You consume some of my components and I consume some of yours.
We each may later pass back these components and users expect identity
to be maintained. I don't expect explicit support for this out of WebDAV
but I would like it to not stand in my way.
> You were neglecting the "activity" concept. Activities are
> there to capture
> a logical change. Activities can have "needed-activities" to
> allow you
> to specify a group of logical changes that combine to form a
> larger logical
> change.
>
> Configurations are there to snapshot the state of the world after some
> number of activities have resulted in a state of the world worth
> snapshotting. So although I believe configurations must be
> lightweight,
> they don't have to be as lightweight as an activity (which must be
> *really* lightweight, since it captures the smallest
> increments of change).
Activities are great and I was thinking about them but they don't enable
sharing of revisions in the way we are looking for. I belive that
activities can be shared (correct?). So I can put one of your activities
in my RSR. How many Activities do we see being in a team environment on
average? less than, greater than or equal to the number fo team members?
I think it is related to the number of logical things that are going on
and that that is >> # of team members (IMHO). So we have to be prepared
for many activities in our RSRs.
If activities are coarser grained, it is likely that I am not interested
in, or perhaps should not have, all of the things that are in your
activity. You are updating components A and B and I am working on A and
C. I want to see your changes to A but not to B. Further, I am
generally not interested in your changes until you have reversioned the
*component*. As I understand activities, I will see all the intermediate
states of the component's constituents.
Activities are a good thing and they do solve real problems for us. I
just don't think we are done in this area.
> Prerequisites (i.e., needed configs) are useful ways
> for users to group/reuse logically coherent resource sets
> but BEWARE!
> Maintaining these dependencies is a NON-TRIVIAL amount of
> work for the
> user. Further, users should not be creating these to
> satisfy the system
> (i.e., webdav) but to help them solve their problems.
> This structure may
>
> or may not fit into some nice hierarchy. I have no
> problem with having
> this capability in WebDAV but we will not use it (much)
> and any problem
> that is solved only by using "needed configs" is not solved for us.
>
> The "needed" configurations are not a general traceability
> links. They
> are a very simple RSR "composition" relationship. Their
> semantics is only
> that if you explicitly specify an configuration revision in an RSR,
> you implicitly select all its "needed" configurations. If
> you explicitly
> specify an activity in an RSR, you implicitly select all its "needed"
> activities.
>
> A composition relation is essential if you are going to scale, i.e. if
> you have thousands of objects, you need some intermediate
> "clumps" so that
> at any level of abstraction, you can just deal with "dozens".
I agree but note that our experience is that the work in maintaining
nested composition relationships which include specific revision
information is significantly non-trivial.
Jeff