> I do not understand our architecture. I use JavaHL via Subclipse so
> code can run on any OS. Why would I want to ask for any of this? I
> do not see why we even expose this. Subversion ought to just know
> what it can do and do it. If we have multiple options on an OS then
> let the user configure their preference on config area.
Well, as it stands now, we currently have two approaches for exposing
auth providers. The proposal is to have one unified approach to make
things easier for developers. This proposal is to create a single way
for getting access to Subversion-aware auth providers. As for telling
Subversion which to use in the config, I think 1.6 adds that capability but
I'm not 100% sure.
> Also, why did we have to do all this work to get SSL cert passphrases
> supported? It seems like we ought to just have an ability to store
> key/value pairs (passwords) and if there is a secure mechanism
> available to do it .. use it.
Well, for OSX it was dirt simple. ;)
> I was pretty shocked to discover that 2 releases after we added
> keychain support on OSX that JavaHL did not even support it because no
> one had added the boilerplate code to the library to ask for it. It
> seems we are broken in this area if that code even needed to be added.
I can't really comment on why this happened but things should get much
easier if we were to go through with this proposal. Instead of all of that
platform-specific stuff in SVNClient.cpp(getContext),
libsvn_subr/cmdline.c(svn_cmdline_set_up_auth_baton) and others, you'd
have one simple function to call to either get a complete list of known auth
providers or you could cherry pick the providers you were interested in and
use them that way. No more direct retrieval of auth providers. No more having
to decide which mechanism for retrieving an auth provider. With this
proposal, we seek to make things easier. If this were already done, you make
a change to Subversion core to support a new auth provider and all consumers
of this new function get the newly supported auth provider for free. Nothing
is required on their behalf. Does this help explain the "why"?
--
Take care,
Jeremy Whitlock
http://www.thoughtspark.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-21 18:13:02 CEST