You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2012/07/26 22:12:41 UTC
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.
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.
Am I missing something? Is this just a holdover from the days when we
discouraged the use of private-but-non-static functions?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Third-party provider funcs in our API: did we expose too much?
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Jul 26, 2012 at 04:12:41PM -0400, C. Michael Pilato wrote:
> 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 would guess it's a simple case of gratuitous copy-pasting,
as in the first provider was made public and the others blindly
followed the same pattern.
RE: Third-party provider funcs in our API: did we expose too much?
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato@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:cmpilato@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
Re: Third-party provider funcs in our API: did we expose too much?
Posted by Daniel Shahaf <da...@elego.de>.
C. Michael Pilato wrote on Thu, Jul 26, 2012 at 16:54:48 -0400:
> On 07/26/2012 04:33 PM, Bert Huijben wrote:
> >
> >
> >> -----Original Message-----
> >> From: C. Michael Pilato [mailto:cmpilato@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.
Agreed that it should be. But if the only svn_subr_* API that _uses_
that option is svn_cmdline_init(), then _de facto_ it is part of the
cmdline API... (if I understand Bert correctly)
Re: Third-party provider funcs in our API: did we expose too much?
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/26/2012 04:33 PM, Bert Huijben wrote:
>
>
>> -----Original Message-----
>> From: C. Michael Pilato [mailto:cmpilato@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 <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
RE: Third-party provider funcs in our API: did we expose too much?
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato@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.
> 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.
(All our libraries expose a version function, so that probably explains the last two)
Bert
>
> Am I missing something? Is this just a holdover from the days when we
> discouraged the use of private-but-non-static functions?
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Enterprise Cloud Development