extending nss and examples/nss a bit

[tridge at samba.org]

Simo,

 > Why should an application dlopen it?

The original reason for using dlopen() to nss interfaces comes from
trying to write applications that access arbitrary nss backends at
runtime. It allows the application to completely control the cacheing
of nss calls, which cannot be done via the C library mediated
interfaces. 

As a good example of this look at nsstest.c. That test application
works nicely against nis+, ldap, winbind and any other nss interface
you want to try it on. It does this without having to recompile the
application. If you link directly to the library then that is
impossible. 

Once you do this I think it is fairly natural to start extending nss
within the spirit of the nss framework of calls. The nss_sidtoname()
is the obvious syntax in keeping with the other standard nss calls,
and I think would be quite a sane extension to actually add to the nss
standard at some stage. While at the moment the call is only available
via dlopen() I hope that it will eventually be available in glibc and
other C libraries to provide a much better degree of interoperability
with the MS world.

In the meantime, having these additional functions in our nss library
does no harm at all, and puts us on track to an eventual situation
where SIDs become first class citizens in the POSIX world. New
standards have to start somewhere :-)

 > > So my proposal would be to build new library named
 > > libwbclient.so and header wbclient.h
 > 
 > In any case I would prefer this option, as putting extensions on a
 > system lib is not very nice imho.

I would very much like to avoid having to have a header that defines
Samba specific structures and expose that to 3rd party
applications. Having a header that provides some prototypes is OK I
think, but if we start going down the track of defining binary
structures that change depending on compiler options then I think we
will be back to the bad sitiation that the nss extensions try to
avoid.

Cheers, Tridge