[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.

--
Joe
---------------------------------------------------------------------
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.