Re: [nssldap] release 0.2 of nss-ldapd

[Andreas Hasenack <ahasenack [at] terra.com.br>]

On Mon, Jun 18, 2007 at 03:29:15PM +0200, Ralf Haferkamp wrote:
> On Tuesday 12 June 2007 09:39, Arthur de Jong wrote:
> > > After reading your docs a bit...
> > > Question: What is the benefit of using your nss-ldapd over the normal
> > > padl software with nscd running?
> [..]
> > So in short, the biggest benefits are that nss-ldapd makes hostname
> > lookups through LDAP work and speeds up namelookup failures if the LDAP
> > server is not (yet) available (because the daemon part is started after
> > the LDAP server is available).
> There are some other advantages I can see from having a daemonized nss_ldap. 
> Those are e.g.:
> - No more symbol clashes when an application that uses nss_ldap is linked 
> agains a different LDAP or SSL library (e.g. Thunderbird is a prominent 
> example which normally uses the Mozilla LDAP libraries.). A work around for 
> this is to link nss_ldap statically, but this creates a maintenance 
> nightmare.
> - Clients using nss_ldap will really only have one connection open to the 
> LDAP 
> Server. Now, even if using nscd, most of the time every client has multiple 
> LDAP connection opened. (udevd being an example, because it is usually 
> started before nscd. Or all binaries using any of the getXXent() calls, cause 
> those are not handled by nscd).
> - Additionally it might get easier to setup some features using a daemonized 
> nss_ldap. (e.g. currently using nss_ldap in a kerberized enviroment is a bit 
> of a hazzle)
> - Some interesting new feature could be added. E.g. offline support in 
> nss_ldap. (For that of course a caching feature would need to be added to 
> nss_ldap)

- one also doesn't have to worry about filedescriptors from the
  application, like closing the wrong ones, etc
- no worries or precautions about the application forking, which is a
  main source of grief in current nss_ldap. Same applies for threads
  possibly.