Re: Activity, Workspace, Configuration

jamsden@us.ibm.com
Mon, 13 Dec 1999 07:11:28 -0500 

From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256846.0043113B.00@d54mta03.raleigh.ibm.com>
Date: Mon, 13 Dec 1999 07:11:28 -0500
Subject: Re: Activity, Workspace, Configuration



I think configuration is too course grained to be the unit of reuse.
Resource and collection are better as they are the finest-grained units
that are manipulated by WebDAV. For example,  a version of a gif file can
be reused in contexts that don't contain all the other images used by some
other application.





"Geoffrey M. Clemm" <geoffrey.clemm@rational.com> on 12/10/99 12:10:31 AM

To:   Jim Amsden/Raleigh/IBM@IBMUS
cc:

Subject:  Re: Activity, Workspace, Configuration


   From: jamsden@us.ibm.com

   <gmc/>
   But I am toying with the idea of proposing to the versioning design team
   that we actually constrain versioned configurations so that revisions
   of a particular versioned resource can belong to at most one versioned
   configuration.  This makes revisions of a given versioned configuration
   much more interchangeable, and allows for significant server side
   optimizations, but it does come at the cost of a decrease in
flexibility.

   <ja/>
   This would seriously inhibit reuse and logically seems arbitrary. When a
   resource matures and stabilizes, it doesn't change that often and is a
more
   likely candidate for reuse. So many configurations of many Web
applications
   would include the same revision. Unless there is some insurmountable
   problem that this would solve, I would not want to consider the
constraint.
   But, perhaps I'm not completely understanding the issue.

It's not a question of whether several Web applications can use the
same revision or not (they can), but rather how they do so.  If revisions
of a versioned resource can be contained only be revisions of a single
versioned configuration, then to use a particular revision of that
versioned resource, you'd have to select a particular revision of the
versioned configuration.

A good analogy is with functions defined in files:

A function cannot be used or referenced on its own, but rather is
selected by specifying a revision of the file that contains that
function.  If you want to use a particular revision of a function, you
have to select a revision of the file that contains that revision of
the function.  If you want a combination of function revisions not
available in an existing file, you have to create a new file revision
that contains the appropriate combination.

Rewritten in terms of files defined in configurations:

A file cannot be used or referenced on its own, but rather is
selected by specifying a revision of the configuration that contains
that file.  If you want to use a particular revision of a file, you
have to select a revision of the configuration that contains that
revision of the file.  If you want a combination of file revisions not
available in an existing configuration, you have to create a new
configuration revision that contains the appropriate combination.

In ClearCase, we call a versioned configuration a "component"
(to be precise, a "development component").  A file is not the
unit of sharing, but rather a component is.  So you pick a baseline
of a component, not a version of a file, when you want to select
something reusable.

Cheers,
Geoff