-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 28 Aug 2002, Bill Studenmund wrote:

>On Wed, 28 Aug 2002, Greg A. Woods wrote:
>
>Why is it an abomination? Well, since you chose to use such a subjective
>adjective, you're probably made up your mind well past openness.
>
>> Adding RADIUS support to nsswitch, for example, might be a very good
>> idea and might make NetBSD more useful for some tasks in some ISP
>> environments than it is today.  I've even considered doing it as a local
>> patch to my own systems, though at the moment I no longer have a direct
>> application in need of such a solution.  It wouldn't even be very much
>> code (and templates exist already where similar stuff has been directly
>> integrated into getpwent() et al without the mediation of nsswitch), so
>> could be added to the default libraries shipped by TNF.  However one
>> thing I would not ever want is a pluggable interface of any kind to
>> allow nsswitch to load such modules at run time, not for this kind of
>> local code, nor for anything else anyone might dream up.  If I can't
>> compile the code directly into my nsswitch library and relink all my own
>> binaries then I don't want that code anywhere near my systems -- it
>> wouldn't be a "solution" but rather a risk and a support problem.
>
>Well, you've chosen to do things in a manner a number of folks haven't.
>They find having to compile each module into each program a support mess.
>
>Yes, our lives are a bit easier in that we have nsswitch, so that there is
>an API all these modules need to use. But it still means rebuilding chunks
>of libraries and programs. We want loadable modules so you don't have to
>do that.

This is right on, though I'd like to make one more point in favor of
loadable modules:  by supporting loadable modules, we make it possible
for nsswitch or authentication to be based on software which we don't
distribute with the base system.

Suppose I want to add the capability to authenticate users against a
PostgreSQL database (a perfectly reasonable thing to want to do).  This
would involve a loadable authentication module which would be linked
against libpq.  If we want to support this in Greg's
everything-is-static world, we would need to bundle libpq with the base
system, or reimplement it completely -- and track changes in
PostgreSQL's protocol over time, and make sure our implementation stays
compatible with theirs.

The alternative, allowing pluggable authentication modules, makes it
trivial to distribute via pkgsrc a pluggable module which would link
against libpq.  An advantage of providing a PAM compatible API (or just
using PAM) for these modules is that we could even use pre-existing
impelementations of this.

Now, if you think that was unpleasant to do with a statically-linked
world, here comes the fun part:  what if, instead of PostgreSQL, I want
to use Sybase?  Guess what -- now we _can't_ ship the libraries needed
to link such a module with the system, and so, without the ability to
add third-party auth modules dynamically, we're out of luck.

- -- 
				Jim Wise
				jwise@draga.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (NetBSD)

iD8DBQE9bT0LN71lEcOYcw4RAtWeAKCulvhriAu2gx/GfEojMYm79d0AIACeLUEx
djLRok/vi0vAeFiNdlynzlU=
=Giti
-----END PGP SIGNATURE-----