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

Re: SWIG and platform-specific auth providers (Was: Python bindings build seems broken)

From: Joe Swatosh <joe.swatosh_at_gmail.com>
Date: Wed, 5 Nov 2008 16:58:17 -0800

On Wed, Nov 5, 2008 at 4:04 PM, Jeremy Whitlock <jcscoobyrs_at_gmail.com> wrote:
>> Unfortunately:
>> D:\SVN\src-release-1.5.x\subversion\bindings\swig\ruby>ruby -rsvn\core
>> -e "puts Svn::Core::VERSION"
>> 1.5.3 (dev build)
>> D:\SVN\src-release-1.5.x\subversion\bindings\swig\ruby>test\run-test.rb
>> test\test_client.rb -v -n"/simp|win|auth|prov/"
>> Loaded suite test_client.rb
>> Started
>> test_add_providers(SvnClientTest): .
>> test_authentication(SvnClientTest): .
>> test_simple_provider(SvnClientTest): .
>> test_username_provider(SvnClientTest): .
>> test_windows_simple_provider(SvnClientTest): .
>> Finished in 18.53 seconds.
>> 5 tests, 13 assertions, 0 failures, 0 errors
>> ------------------------------------------------------------------------------
>> Those tests are why I came up with the patch in the first place.
>> While I've never used them, I think they have been "explicitly exposed."
> Well, what is being proposed is to no longer use the functions that
> create and return a platform-specific auth provider directly:
> http://www.nabble.com/-PATCH--Refactor-platform-specific-auth-provider-access-tc20330991.html
> So instead of using svn_auth_get_keychain_simple_provider to create
> the simple keychain provider, you'd use
> svn_auth_get_platform_specific_provider to get the platform-specific
> provider. This means no more #ifdef statements, no more conditional
> binding exposure and no reliance upon libraries that might not be
> there. (That last example is in the case of gnome-keyring and
> kwallet. As it stands right now, if you build on a system that does
> want to build in gnome-keyring or kwallet support, at runtime, all
> bindings will fail.) If this patch is committed as-is, the explicit
> use of the platform-specific auth providers in Ruby should be removed
> and replaced with the new api. Does this make sense? I think that is
> the only impact of the suggested patch and the Ruby bindings.

Yes we would expose the new API from the Ruby bindings.

My compatibility concerns arise from your statement that the "the explicit use
of the platform-specific auth providers in Ruby should be removed." Since we
put them out there it seems like we have to support them, but I realized as I
was reviewing your refactoring in the other thread that we could make the Ruby
bindings support the old APIs through this new interface.

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-06 01:58:30 CET

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.