On Thu, 2005-07-28 at 18:07 +0200, David Anderson wrote:
> The current svn_repos_authz_func_t, ie. the callback function
> prototype for authz lookup functions, has no parameter to describe the
> type of access required. This means one callback per kind of authz
> lookup: one for read, one for write. But that means the commit editor
> won't be able to ask authz to do a recursive lookup (unless we pass 4
> authz callbacks to the commit editor, a total of 8 new parameters...).
> The solution here is to revv the callback prototype and have it take
> an extra REQUIRED_ACCESS parameter, whose value can be any mix of
> read/write/recursive.
Historical note: I originally asked that the callback be named
svn_repos_authz_func_t instead of svn_repos_authz_read_func_t so that we
wouldn't have to invent a new callback type for the commit editor. I
did not realize we'd have a need to query read access and recursive
access (this was before we discovered the weaknesses in mod_authz_svn as
it applied to copy operations), so I may have made things worse by
requesting that change.
> This prompts a policy question for me: How do we manage revving
> callback APIs?
To rev a callback API, one has to rev every function which uses the
callback type.
That's probably more churn that is really necessary here, since the new
feature isn't needed by existing functions. So what I would do is make
up a new name for the extended svn_repos_authz_func_t (as opposed to
svn_repos_authz_func2_t, since that name would imply that
svn_repos_authz_func_t is deprecated) and make the commit editor use
that. Then you can leave the existing APIs alone.
The trick, of course, is coming up with a name which isn't confusing,
since the obvious one is taken. My advice is to give up on trying to
convey the historical relationship with the name, and just use comments
to explain why we have two names for very similar concepts. Then you
can pick a name like svn_repos_authz_callback_t which means the same
thing but is worded differently.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 29 07:38:05 2005