--On Friday, January 31, 2003 11:53 AM -0600 Karl Fogel
<kfogel@newton.ch.collab.net> wrote:
> Justin Erenkrantz <jerenkrantz@apache.org> writes:
>> 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.
>
> These two paragraphs seem to be in contradiction to me. The
> prompting provider should not save, and any provider of two char*'s
> should be able to save that pair. But the prompting provider is a
> provider of two char*'s... What am I missing? :-)
It *could* save it. But, the prompting provider should be a
read-only provider. What you and Sussman are advocating is that the
prompting provider use another abstraction layer so that it can save.
I'm saying that breaks the first abstraction layer of the providers.
> But in any case, the point is, we've been saving prompted auth data
> up till now (except when no-auth-cache is explicitly requested), and
> changing that behavior is outside the scope of issue #724.
It would still be saved under our scheme. It's just that the disk
provider would save it. You are thinking the credentials are
symmetrical. They aren't (and was the point I was trying to make
with the char*'s). One provider could read a credential, while
another might save it. The only reason to offer the one that
produced the credential to save it first is to allow 'updating' of
credentials to occur without minimal hassle.
> "Thanks for the report. What is the order of your providers?"
> "Sorry?"
> "Uh, just show us your ~/.subversion/auth_providers..."
No, I'm not meaning for users to control the ordering of providers
yet. I'm meaning for the client programmer to control the ordering.
Users probably won't be aware of the ordering at all. Nor should
they be. But, the client programmers must be. -- 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 19:43:41 2003