"Sander Striker" <striker@apache.org> writes:
> > Our simple prompting provider can, because it uses the same
> > auth-storing function that the WC-cache-reading provider uses.
>
> 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(!)).
Consider the alternative, Sander. Suppose we have 5 providers
registered that all handle the same type of credentials. At some
point, one of the providers provides successful credentials, and now
the ra layer calls svn_auth_save_credentials(). If the provider which
produced them is unable to save things at all (like our prompt
provider), then you want to simply loop until you find a provider that
can? How will you even *know* which provider saved the creds? Are
they now in some svn-agent store? Or in some ~/.subversion/ store?
In a keyring? I don't want non-deterministic storage!
So while I think non-deterministic *retrieval* is fine, only the
provider that created the creds should save them. That means that
each provider needs to be a "standalone" piece of work, completely
capable of saving anything it generates.
Yes, I hear your objections to having to re-implement similar code in
each provider. But that can be done by simply factorizing and sharing
common underlying routines, which we've already done in this case.
(Our two existing providers have save functions which share a common
routine.)
I should point out, though, that Karl had a really interesting idea
yesterday. It would be neat if a provider could somehow use another
provider as a "delegate" when saving. In your example above, Sander,
the prompt-provider could normally have no save routine, but when
registered alongside an svn-agent provider, it could somehow have a
"pointer" to the svn-agent-provider's save function. I'm not sure how
this API would work. The code which registers providers would somehow
need to be able to look over a list of already-registered providers,
and choose a delegate for saving. Hmmmm.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 31 15:57:44 2003