Re: How to create configurations
jamsden@us.ibm.com
Mon, 5 Apr 1999 23:00:27 -0400
From: jamsden@us.ibm.com
To: ejw@ics.uci.edu
cc: ietf-dav-versioning@w3.org
Message-ID: <8525674B.00119035.00@d54mta03.raleigh.ibm.com>
Date: Mon, 5 Apr 1999 23:00:27 -0400
Subject: RE: How to create configurations
Jim,
Unfortunately, I did mean up to the root. But putting a parent in the
configuration only puts the parent, not its members into the configuration.
This is required to recreate the namespace what was used to access the
resource when it was placed in the configuration. We can't do "to the root
of the project" because we don't know what a project is, or what role some
parent collection plays with respect to its members other than containment.
So in your example below, the configuration for program1 would contain
program1, jim, and people. That is, when you put a configuration containing
program1 in your workspace RSR, the name resolution must start with the
root and ask does the selected version of root have a collection called
people in this workspace. Becuse collection people is in the configuration,
the workspace name resolution algorithm can get the revision of people from
the configuration and recursively ask if it has a member called jim. This
process continues until you get to the program1 "project" which I assume
contains some leaf resources.
So one way to address these issues is to examine what happens when the
configuration is used in the workspace as a revision selector. A
configuration can specialize how it looks up a URL and returns a revision,
but the semantics of how the workspace traverses a URL pathname resolving
each entry is independent of how a revision selector looks up its revision.
Jim Whitehead <ejw@ics.uci.edu> on 04/05/99 07:21:44 PM
Please respond to ejw@ics.uci.edu
To: Versioning <ietf-dav-versioning@w3.org>
cc: (bcc: Jim Amsden/Raleigh/IBM)
Subject: RE: How to create configurations
> Adding a resource to a configuration adds the URL of the resource and
> its parent collections recursively up the collection hierarchy to the
> root. The URL must refer to a versioned resource, and the revisions
> selecded for the configuration must be immutable.
Jim,
Thanks for taking the time to write this message about configurations -- it
really helped my understanding a lot.
However, reading through your post, I was struck by the requirement I
quoted
above. It seems to me there are many use cases where you don't want to add
the URLs of parent collections all the way to the root.
For example, if I have a Web server set up so my personal working space is:
http://davserver.uci.edu/people/jim/
(where other users are added under /people/)
I wouldn't want to have /people/ added into a configuration of some project
which starts under /jim/. I'm hoping you really meant "to the root of the
project" or something like that, where, if in the example above I was
working on two projects:
http://davserver.uci.edu/people/jim/program1/
http://davserver.uci.edu/people/jim/program2/
(where /program1/ and /program2/ are the root URLs of a hierarchy of Web
resources for source code, design document, requirements, etc.)
In this case, I would want a set of configurations for /program1/ and a set
of configurations for /program2/ (and never the two shall meet).
- Jim