On 07/26/2012 04:33 PM, Bert Huijben wrote:
>> -----Original Message-----
>> From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
>> Sent: donderdag 26 juli 2012 22:13
>> To: Subversion Development
>> Subject: Third-party provider funcs in our API: did we expose too much?
>> Can anyone explain to me why the following symbols are exposed in the
>> Subversion API?
>> I mean, I recognize the value of what each of these functions provides, but
>> it seems to me that svn_auth_get_platform_specific_client_providers()
>> much obsoletes all them.
> You currently can't initialize a non cmdline behavior without these apis.
> (The only api that calls them for you also Initializes your console for
> That might be part of the reason.
Why not just use svn_auth_get_platform_specific_client_providers(), which is
just a wrapper around svn_auth_get_platform_specific_provider() that
actually honors the runtime config? Okay, I can spot one platform-specific
provider that ..._providers() doesn't pick up for you, and that's the
Windows SSL server trust provider. But I'd be surprised if we couldn't just
plop that one into the list that ..._providers() returns, too.
>> What's more, this latter single function actually honors the runtime
>> configuration's "password-stores" option value (which dictates the
>> availability and preferred specific ordering of third-party providers),
>> while the aforementioned list of interfaces almost begs API consumers to
>> fetch providers individually and plop them into the auth subsystem's
>> providers list without regard to the user-configured availability and order.
> That passwords-stores option is part of the cmdline api.
What? The password-stores option is part of the Subversion runtime
configuration. I've never heard it proposed that our runtime configuration
parameters were somehow specific to the command-line client. If that's the
case, we have a whoooooooole lot of layering violations all over our codebase.
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-07-26 22:55:30 CEST