Ben Collins-Sussman <sussman@collab.net> writes:
> Philip Martin <philip@codematters.co.uk> writes:
>
> > Why can't that blob simply be passed by the application
> > directly to the provider when it registers the provider?
>
> In the case of libsvn_auth, the runtime data that a certain provider
> needs isn't always available at registration time.
>
> Sometimes it is: consider --username or --password.
>
> Sometimes it's not: we don't know which wc/access-baton to search for
> cached creds in, at least not until we're in the middle of
> svn_client__open_ra_session. Or consider that a certs provider needs
> a 'realm' -- which only comes when server sends the challenge.
No, I still don't really understand.
If the core, generic Subversion code is adding an access baton to the
hash for one of the auth providers it must effectively be doing it for
all the auth providers. There is no need for that to go via a hash,
it could simply be part of a structure passed to the auth routines.
I don't know much about the mechanism of the certs provider (does
anybody?), is the generic Subversion code going to understand the
concept of a realm? Isn't that specific to the certs provider? If it
is specific to the certs provider then the generic code cannot put it
into the hash. The only way it can get into the hash is if some part
of the the certs provider itself puts it there, possibly because it
wants to refer to it later. But it wouldn't do that, it would just
store it in the provider baton. If, on the other hand, the generic
code does know about the realm then there is no need to disguise it in
a hash.
I can see that one could do it all via a hash, I just don't see why
one would choose to do it that way. It strikes me as an unusual way
to do things. As far as I can see the hash contains two kinds of
keys, there are those known at registration time and those that are
not. The items known at registration time are "fixed" they don't
depend on the context of the call and could be passed directly to the
registration routines. --username is an example of a fixed item. The
other items must be understood by the core, generic Subversion code
and may depend on the context of the call, these could be passed via a
normal C structure. The access baton is an example of variable item.
It boils down to this: the hash should be replaced by a structure of
the things that the core, generic code knows about. Everything else
gets passed at registration. Is the certs "realm" really something
that doesn't fit either of these categories?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 27 00:34:26 2003