On Wednesday 28 December 2005 00:31, Lieven Govaerts wrote:
> as a result of the thread on the users list, and a discussion I had tonight
> on #svn-dev, I want to propose implementation of two new features.
Now that 1.3.0 is (finally!) out, I'd like to get back to this.
> Allow to assign read/write access in the authz algorithm for roles instead
> of groups, and on branch types instead of specific branches.
> Two changes ( extensions ) in the authz algorithm are needed:
> - add the concept of a role, and allow access rights to be given to a role
> instead of a group
I'm in favour of this, as I find it adds an interesting bonus capability to
our authz system, while at the same time remaining perfectly backcompatible
with existing stuff.
> - allow wildcard matching to match branch types instead of actual branches
This is a little more tricky. On the concept I'm +1, because it adds the
flexibility required to make roles work properly. On the implementation I
have a problem, because it makes all authz lookups have to crawl whole files
to locate a glob matching section.
The pain will be eased though, by two things:
- Having wildcards will (I reckon) massively decrease the size of the authz
file in some common use cases, so the cost of crawling the file goes down to
a bearable level.
- The authz file gets crawled once when it is opened. We could add tests
that set a flag if glob patterns are found during this crawling, and only do
glob-crawling if it is set. That would restrict the performance impact to
the users actually using the feature, which is fine by me.
So, all in all, I'm tentatively +1, because the performance impact will only
happen to people using the feature, and should be fairly small.
Also, note that both features are completely independant: Role-based access
control uses the repository name to check for role access, and wildcards only
apply to paths inside repositories. Both are required to completely solve
Lieven's use case, but they aren't interdependent.
So, can we have other opinions on these two proposed features?
I've already told Lieven that I'm ready to implement these once their design
has been reviewed and approved. But as we've basically been both designing
and thinking about this, we need untainted minds to look at the problem and
tell us what's wrong with it.
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 4 23:47:08 2006