W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1999

Re: Can you move a locked file?

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Wed, 27 Oct 1999 21:56:27 -0400
Message-Id: <9910280156.AA26691@tantalum>
To: w3c-dist-auth@w3.org

   From: Greg Stein <gstein@lyra.org>

   Then why don't we look at the problems caused by selection rules, rather
   than assuming they are fixed and making everything else fit into their
   little world?

First I should emphasize that these issues only arise with level 3
versioning, which introduces versioned collections.  Level 1 (Core)
and Level 2 (Activity and Configuration) versioning do not provide
namespace versioning, and therefore do not have this problem.

But for many applications, versioning the URL namespace is essential,
so we still need to face this issue for clients that desire support
for namespace versioning.

   Why can't we simply constrain the selection rules better, thereby
   avoiding the issues that you foresee with locks?

That is the essence of the fallback proposal I mentioned in an earlier message.
In particular, you would need to:
a) only provide URL protection in the default workspace
b) constrain the selection rules in the default workspace

Restriction (a) is needed because no matter how you restrict the
selection rules, if you allow an arbitrary number of workspaces to
have protected URL's, the cost of pre-computing the effect of even
something simple like a label request will become arbitrarily large.

Restriction (b) is needed because even if you only support URL
protection in a single workspace, some selection rules (such as
configurations and baselines) affect an arbitrary number of
resources, and therefore the effect on the namespace of a baseline
change would require arbitrarily large costs to pre-compute.

Doing away with configurations and multiple workspaces entirely
would eliminate much/most of the value of versioning.

Received on Wednesday, 27 October 1999 21:56:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:20 UTC