> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpil...@collab.net]
> Sent: donderdag 26 juli 2012 22:55
> To: Bert Huijben
> Cc: 'Subversion Development'
> Subject: Re: Third-party provider funcs in our API: did we expose too much?
>
> On 07/26/2012 04:33 PM, Bert Huijben wrote:
> >
> >
> >> -----Original Message-----
> >> From: C. Michael Pilato [mailto:cmpil...@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.
svn_auth_get_platform_specific_client_providers() and the password-store option
were invented/added in Subversion 1.6. All those Windows and the MAC apis were
available in 1.5.
I designed SharpSvn based on Subversion 1.4 with an eye on releasing it after
1.5...
So I expose this api hooking in SharpSvn. But I don't think the api users would
mind if I started following the passwords-stores argument for ordering the
storage providers.
Bert
