Greg Stein <gstein@lyra.org> writes:
> Note that there is a potential ordering problem, similar to the kinds of
> module-related ordering problems in Apache 1.3. The order that you retrieve
> might not be the order that you want to save. The "right" answer (which is
> what Apache 2.0 did) is to have separate lists: one for fetching and one for
> saving (A2 does this with the hooks each being their own ordered list rather
> than a global module-ordered list).
>
> However, two lists would be a pain, and is only to solve boundary cases. The
> proposal continues with a single list, but points out that you can
> instantiate providers (e.g. the provider_baton contents) differently to
> produce different behavior in your overall provider list.
I think we managed to hash out all of the problems that were bothering
people.
I'm documenting a new libsvn_auth proposal here that I think should
satisfy absolutely everyone. Be sure to read the entire proposal,
because it makes sense as a whole, rather than in pieces. :-)
* Go back to looping over provider save-functions.
* Allow providers to *not* have save functions, such as our
prompt-provider.
* Declare a new policy: only applications get to instantiate and
register providers. They have exclusive control of ordering.
* To enforce this policy, delete our svn_auth_register_provider()
interface. Instead, when the application calls svn_auth_open(),
it will pass it a static array of providers, ordered exactly the
way it wants. This prevents any future layers from registering
providers later on: the ordered providers are attached to the
auth_baton at birth.
* Karl and I were previously objecting to the (perceived) danger of
assuming that a single ordering would always work for both reading
and writing. Greg points out, however, that in practice this
isn't much of a problem; if an application ever *does* discover
that a single ordering won't work for both, it can force
provider-constructors to grow new arguments. These new args can
subtly change provider behavior so as to allow the single ordering
to continue working for both reads and writes. It's an "escape
hatch" in case of future problems.
* Admit the existence of the following problem: long after providers
are constructed and registered by the application, they may need
"runtime parameters".
Example 1: the wc-provider needs a wc to look at, but we don't
know the wc until libsvn_client is about to open an RA session.
Example 2: when the RA layer receives a certs challenge, it will
get "machinename" and "realm" information that will need to hand
off to an already registered certs-provider.
* Proposed solution: place a hashtable within the auth_baton which
holds "runtime parameters".
* create public functions to get/set "runtime parameter" values,
callable any time, by anyone.
* provider implementations will look for specific runtime params
in the hash that they need; if not present, they simply
fail to return credentials (return NULL). (and obviously,
each provider will document what runtime params it needs.)
I think this proposal has all of the desired features:
1. Gives Sander and Justin the flexibility they want; providers can
"cooperate" by virtue of ordering, rather than by the forced
sharing of code in implementations. (provider implementations
remain insular.)
2. Settles my and Karl's mind -- we're no longer freaked out about
using a single ordering for both reading and writing.
3. Removes all the absurdity around registering providers "late" in
the game, or implementing an registration-ordering interface.
4. Prevents our future problem that David would have hit when
writing our certs provider. :-)
What say ye?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 31 23:14:36 2003