Karl Fogel <kfogel@newton.ch.collab.net> writes:
> Ben Collins-Sussman <sussman@collab.net> writes:
> > * get ra_local to stop using the old auth system.
> >
> > --> it wants to pull a username; does this mean writing two
> > new providers (wc and prompt) just for the "username" kind
> > of credentials? Or maybe just one big provider that tries
> > all four methods on successive attempts (cmdline arg, disk,
> > getuid, prompt)? I'm leaning toward the latter.
>
> (I might be just confused, but...) I thought the whole point of the
> multiple-providers-per-credential-type was precisely so we could write
> different providers here and try them in a loop. That way, if we
> learn some new method of getting "username"-style credentials, we just
> write a new provider, i.e., we don't have to ponder the question "Does
> this become a new kind of attempt in our one big provider, or should
> it get its own provider?", because the answer is "It gets its own
> provider."
Yes, it's nice to have mulitple providers for a single type of
credentials, each nicely encapsulated as a single method.
But in this one case, *only* ra_local wants credentials of type
"username". If we were to create a wc provider, prompt provider, and
getuid provider, it would feel really overengineered to me. Why?
Because there's *no way* a username can "fail" to work with ra_local.
There's no auth challenge happening -- ra_local only wants the
username to create an svn:author property on the commit!
It seems ridiculous to have a bunch of sequenced providers in this
case. I imagine a single provider like this:
* honor --username/--password first
* then look in wc
* then getuid
There's no point in prompting. getuid can't possibly fail; only the
first two methods may be unavailable.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 5 03:06:27 2003