[KLUG Members] ApacheDS

[Adam Tauno Williams]

> Anyone care to compare the new Apache Directory Server to OpenLDAP?
> How about for someone looking to install their first LDAP server,
> which is their best option?

The project description:
"ApacheDS is an LDAP and X.500 experimentation platform. Its backend
subsystem and frontend are separable and independently embeddable. It
provides a server side JNDI LDAP provider that directly interacts with
the backend storage. It is powered by SEDA (Staged Event-Driven
Architecture), which can handle large amounts of concurrency."

Just from that I'd be very hesitant to even touch it.

1.) ***WHY*** support X.500?  X.500 is terrible, heavy, and complex.  If
you even begin to think LDAP is confusing enough then X.500 will pop
your skull like a ripe zit between two fingers.  And X.500 is dead.
2.) "experimentation platform"
3.) "server side JNDI" - This means Java.  Java has, IMNSHO, become even
WORSE than Perl (and thats really really really hard) in being on just
this side of totally unsupportable.  How many packages does Tomcat
depend on?  It's INSANE!!!  xerces, xerces-j2, ant, jakarta,
jakarta-struts, etc... I could go on and on and on and on and on and on
and on and on......................  Got a bug?  Got even the remotest
hope of determining which of the hundreds (if not thousands) of jar
files it is actually manifesting from?  I've seen with my own two eyes
very smart very talented Java developers look at something as simple as
an XSLT transform go kapluey and then shrug their shoulders and say:
"Huh, oh well."  I both expect and hope that .Net will grind Java into a
carpet stain beneath it's big corporate boot;  Java has gone totally
wrong.

That and from the description -
"Our primary vision (others also outlined below) is to build an
enterprise directory server platform (and its components) where other
Internet services snap in to store their data within the directory so
they may be managed using LDAP. From the image above you'll see the
architecture is designed so services besides LDAP like DNS, DHCP, SLP
and Kerberos will snap in"

I don't get it.  This seems entirely the wrong way around; not to
mention that almost all of this is already possible.  I got my IP
address from an LDAP/DHCP server,  this message will be authenticated
against LDAP by the MTA, the MTA will use a mailer table in LDAP to
locate the external gateway, and that host will lookup the recipient
domain's MX record via a DNS server using an LDAP backend.  Oh, and the
KDC I got this ticket from,  it uses the key store in LDAP, where my
password hashes are that get changed via a Samba PDC using a SAM stored
in LDAP.  I could support SLP, it is just that no clients support SLP,
so why bother.

But it is a neat idea to expose directory 'event' logic via SOAP[UDDI]
and what not.  But it seems a more straight-forward approach to do this
in front of the DSA using business logic / work flow rules than to turn
the DSA (which absolutely needs to always work) into some gargantuan
construct with a bazillion dependencies.