Ben Collins-Sussman <sussman@collab.net> writes:
> Yes, we could do that. But now we're back to the idea of the Giant C
> Structure which contains the "Union of All Possible Runtime Values Not
> Known At Startup, For All Possible Providers". And Brane has already
> explained why that's a yucky thing. Do you not agree it's yucky?
It's not a "Union of All Possible Runtime Values Not Known At Startup,
For All Possible Providers". It only includes those parameters that
the core, generic Subversion code understands. Now if the core,
generic code is to add these parameters to the hash, it needs to know
which key to use and what form the value takes (string, integer,
etc.). I don't see why this is more yucky than adding those same
parameters to a structure, where the element name (the hash key) and
the element type (the form of the hash value) can be checked by the
compiler.
> > 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?
>
> No, the certs realm is in the latter category: "those things that are
> not known at registration time". When neon receives a certs challenge
> from the server, it passes the server-specific information (such a
> "realm", etc.) into a callback. The callback then places the info
> into the auth_baton hash (or into the Giant C structure), and then
> calls svn_auth_first_credentials(auth_baton, SVN_AUTH_CRED_CLIENT_CERT).
OK, lets assume that I'm going to write the certs provider and I'm
going to do it *outside* Subversion, i.e. it's my custom provider.
Which bit of code is going to add the realm to the hash? It cannot be
the core, generic Subversion code as that doesn't know anything about
realms. The only thing that can do it is my provider specific code.
So why would I bother with the hash at all? My provider specific code
is just going to stick it straight into the provider specific access
baton, as a const char* or something.
Now, lets assume it cannot be done that way, i.e. assume that for some
reason I cannot use my provider specific code to add the realm to the
hash. [Note: when I say "add to the hash" I just mean "pass the
parameter", as I said, I would put it straight into the provider baton
rather than add it to the hash.] If the provider specific code cannot
do it, then the core, generic code must do it. That means the core,
generic code needs to understand realms explicitly. It needs to know
that functionX returns a const char * realm. It needs to know that
the char * is to be added to the hash using key SVN_AUTH_REALM. How
is that better than simply setting a struture element something->realm
to the char *? Note that the core, generic code has to know the key,
there's no way it can be a key specific to my custom provider.
I'll say again, I can see that a hash works, I just think it's a very
odd way to write C. I'm a C++ programmer so I expect strong type
checking, perhaps you are all Python programmers...
--
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 03:08:02 2003