"Sander Striker" <striker@apache.org> writes:
> Ewww. This seems to defeat the whole purpose of the pluggable
> provider API. Guess what happens if I want to use, say, an
> svn-agent provider and a prompting provider? Now I have to either
> reimplement prompting in the svn-agent provider, or, implement
> a seperate prompting provider (can't reuse the svn prompting
> provider since it will write my creds to disk(!)).
No, I think it's fine.
The system is pretty simple: for each type of credential, you can
register a set of providers. Each provider may or may not have a save
function; if it does, then a successful authentication through that
provider will invoke its save function. (I know you know all this,
I'm just summarizing for others who may not be following as closely.)
The fact that this particular prompting provider's save function
happens to save stuff in the working copy, which may or may not be the
same place some other providers save, is irrelevant. If for some
reason it's a bad idea to save prompted information in this way, then
that provider shouldn't have a save function, or should have a
different save function.
But it has nothing to do with whether or not an svn-agent provider
preceded (or followed) this prompt provider in the sequence. The
presence of an svn-agent provider is not what makes the prompt
provider's save function desirable or undesirable -- rather, a certain
type of saving is *inherently* desirable or undesirable, and the
presence of an svn-agent provider is the result of that decision, not
the cause.
If there are two possible ways the prompt provider might save -- say,
disk versus agent -- then either the prompt provider's save function
should have conditional code to DTRT, or the get-function that returns
the prompt provider should take a conditional that indicates which of
two alternative save functions to use. This is no big deal. Writing
two code paths for saving is a) unavoidable anyway, if there are two
possible way to save, and b) very easy.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 31 17:31:42 2003