[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "SVNAuthorizationShortCircuit or something similar"

From: Josh Gilkerson <jwg_at_google.com>
Date: 2007-04-03 01:03:37 CEST

The main issues I have with the existing work are along the same lines
as Justin.

Most importantly, there seems to be a lot of duplication of code
between the dav and auth modules using the artem-soc-work method.

Less important practically, but still important is that including the
auth logic in the dav module breaks the separation of roles between
the two modules. Introducing an direct call to the auth module does
the same because it means that the dav module has some bit of
information about the auth handling, but to a lesser extent than if it
does major parts of the handling itself.

If anyone has objections to this area of exploration, please speak up.
 I'm not proposing anyone else write the code, just hoping to get a
solution that is acceptable to everyone.

My plan for implementation is to:
- introduce a new configuration setting that determines whether the
optimization is used or not
- introduce a provider in mod_auth_svn that will export the function
or functions to be accessed from mod_dav_svn

I would like comments from anyone interested on any points that need
to be made and any pitfalls they see.

Are there suggestions for the directive name/syntax? Suggestions:
SVNAuthorizationShortCircuit [yes|no]
SVNDavAuthzDirect <provider_name>

Are there suggestions/requirements for the group and name of the
provider that mod_auth_svn will register. I am fairly new to apache
hacking and I don't want to violate any requirements in this regard.
I have been thinking of choosing a group name and then taking the
provider name from the configuration directive.

Josh

On 3/28/07, Justin Erenkrantz <justin@erenkrantz.com> wrote:
> On 3/27/07, Max Bowsher <maxb1@ukf.net> wrote:
> > out, exactly. At some point we're going to need to resolve the
> > philosophical differences in approach between Justin and I.
>
> I believe I've detailed quite clearly already why the approach taken
> in that branch is flawed. I really do hope that the approach I
> outlined would satisfy your requirements for a 'faster' authz - while
> not requiring a lot of inappropriately duplicated code. -- justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>

-- 
Josh Gilkerson
Software Engineer
Google, Inc · MV-1600 Plymouth (HQ)
+1 (650) 253-1667 direct
+1 (859) 608-7827 cell
jwg@google.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 3 01:04:10 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.