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

Re: Third-party provider funcs in our API: did we expose too much?

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 26 Jul 2012 16:54:48 -0400

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
>> public
>> Subversion API?
>>
>> svn_auth_get_platform_specific_provider
>> svn_auth_get_windows_simple_provider
>> svn_auth_get_windows_ssl_client_cert_pw_provider
>> svn_auth_get_windows_ssl_server_trust_provider
>> svn_auth_get_keychain_simple_provider
>> svn_auth_get_keychain_ssl_client_cert_pw_provider
>> svn_auth_get_gnome_keyring_simple_provider
>> svn_auth_get_gnome_keyring_ssl_client_cert_pw_provider
>> svn_auth_get_kwallet_simple_provider
>> svn_auth_get_kwallet_ssl_client_cert_pw_provider
>> svn_auth_get_gpg_agent_simple_provider
>> svn_auth_gnome_keyring_version
>> svn_auth_kwallet_version
>>
>> 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()
>> pretty
>> 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
> you)
>
> 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

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.