Greg Stein <gstein@lyra.org> writes:
> Should have posted the header before rewriting :-)
No worries. I'm used to rewriting and rewriting. :-)
> This won't work...
>
> 1) The RA layer should not do anything with prompts or echo status. That is
> just "out of scope" for RA -- leave it to the callback function.
>
> 2) The RA layer should not fetch items as individual units. Consider the
> user/password situation in a GUI. The pair are fetched at the same time.
> The point here is that stuff is fetched as a semantic group, rather than
> "fetch A, then fetch B, then C".
> (and I dunno why you'd use an apr_array_header_t since the set of items
> is known in advance and static)
>
> 3) Saving information is similar: based on the semantic, different things
> are saved. You sure wouldn't want to save the password for that SSL key,
> but you would for a plain-text HTTP password.
>
> Each "type" of authentication is going to have a way to get the needed
> pieces, and to save the appropriate pieces.
So in other words, even though RA is pulling info now, you're saying
we *still* need to create specific structures for specific protocols?
Are you sure this isn't being overly strict?
Hmmm. Thinking about it, I suppose that even the "username" object
can't be shared between protocols. When ra_local pulls a username,
the client should return the process owner. But when ra_foo pulls a
username, it may be trying to get it along with *all* auth info from
some random file in ~.
You make sense, will rewrite. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:41 2006