--On Friday, January 31, 2003 8:54 AM -0600 Ben Collins-Sussman
<sussman@collab.net> wrote:
> 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!
Um, no. Sander is right. It's not non-deterministic. It's fully a
function of the ordering. You seem to have forgotten that with the
'prepend' patches which took out the ordering. This is why the
ordering should have been an integer with something similar to the
APR hook ordering constants (i.e. REALLY_FIRST, FIRST, MIDDLE, LAST,
REALLY_LAST). The client determines what is the 'preferred' read and
save mechanism by the ordering they place the providers in.
I *did* bring all of this up when I talked about the
svn_auth_save_credentials function on this list. I realized you
weren't completely comfortable with how this function should work.
In the end, you don't care which provider saved the credentials. It
doesn't really matter. All you need to know is whether it was saved
or not. You should be able to rely upon the fact that since it was
saved, any subsequent retrievals should get that credential back.
How it does it and what provider did it isn't important.
> 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.
No, no, no. Prompting provider should *not* be implementing a save
function. Doing so completely violates the abstraction.
This is why there are multiple credential types. A username/password
credential is just that - two char*'s. Any provider should be able
to save that pair. A SSL key provider should probably only be able
to read keys (writing a SSL key is problematic). A username provider
should be able to write the username in any manner it sees fit.
I agree as an optimization that we *could* try to give the provider
which generated the token first shot, but then if it fails (or
doesn't have it implemented), we should be trying all of the other
providers.
> 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.)
Then, they should be independent. If they share common code, they
are probably the same provider. Please stop that. The providers
themselves are already one level of abstraction. You don't need
another one. This is a major red flag...
> 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.
Eww. Over-engineered to the extreme. -- justin
---------------------------------------------------------------------
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:48:06 2003