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

Re: svn commit: rev 4685 - in trunk/subversion: include libsvn_wc libsvn_client libsvn_auth

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-01-31 23:11:20 CET

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

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

* 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

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.