krb5 thread support and excess support libraries -- seeking

[Henry B. Hotz]

Short comment:  I disagree.  ;-)

On May 6, 2004, at 3:06 PM, krbdev-request at mit.edu wrote:

> I do not think that minimizing number of libraries is a valid goal in
> and of itself although I note that it does interact with some of the
> goals expressed above.

A programmer new to Kerberos is not going to expect that the number of  
libraries is so large that a special tool is needed just to determine  
what to link (unless *perhaps* that tool is GNU libtool).  Given shared  
libraries isn't it best to just put everything in one library and make  
the build process take care of the specifics of what's local OS, vs.  
Kerberos support functionality (like com_err)?  Who understands these  
dependencies better, the Kerberos developers, or the "users" developing  
Kerberized applications?

(OK, I'm being extreme for the sake of making the point.  I think 3  
libs, an MIT-API lib, a GSSAPI lib, and one for server-unique functions  
would be OK.  Also it's OK if the latter two depend on the former.   
Furthermore no one's going to be surprised at needing libs like com_err  
and socket for support if they are part of the OS.)

I see the major problem facing Kerberos as getting it adopted properly  
by all the different applications that ought to include support.  That  
suggests that making it easy for experienced programmers who are  
inexperienced with Kerberos should be a priority.
------------------------------------------------------------------------ 
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu