- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Wed, 27 Oct 1999 21:56:27 -0400
- 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. Cheers, Geoff
Received on Wednesday, 27 October 1999 21:56:30 UTC