Hi, I gave a look to the introduction. It looks interesting and a clear sign that LDAP is entering a relative maturity, if even people from other fields junp in and develoips fot it. It is going to help Java developer to enter the world of LDAP, for they being notoriously so SQL minded. One is sure for me: I'm experiencing rapid growth in avaliability and performance needs, where the directory has to stand huge loads and guarantee very high availability figures. For the time being (and at least for some years to come) such a solution is not going to be enterprise ready. It is going to be a neat, local LDAP for the J2EE developer. And now it comes to my concern: a developer is in love with LDAP triggers, and build her applicaton around them and later she discovers that the application is not going to run on the enterprise directory of its customer... Is there any effort to get these triggers into standards? Can you poin me to more documentation? This could be an interesting idea.
mit freundlichen Grüßen Giovanni Baruzzi [EMAIL PROTECTED] _____ Von: Ersin Er [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 15. Dezember 2006 21:26 An: [email protected] Betreff: [ldap] Re: Apache DS vs. others Hi, You may want to check upcoming User's Guide: http://cwiki.apache.org/DIRxSRVx10/apacheds-v10-basic-users-guide.html ;-) On 12/15/06, Adam Tauno Williams <[EMAIL PROTECTED]> wrote: > Can someone point out whether Apache DS is really taking on enterprise > level (use cases are very welcome)? I could not see why one would prefer > Apache DS over others (for example OpenLDAP), unless he requires non-ldap > features like UDDI... I played with it some time ago; unfortunately my exact notes are lost because of a fire. :( I began my poking with this article - http://www.screaming-penguin.com/main.php?storyid=4972 Apache DS is certainly interesting; it is very much like an Open Source Active Directory server than a straight-up LDAP server. It does *ALLOT* of stuff beyond simply serving as an LDAP DSA. My recollections are.... (A) Compared to OpenLDAP - *SLOW*. Not surprising C & BDB verses a huge JBoss monster, but OpenLDAP wiped the floor with it. But, again, as far as performance goes a properly tuned OpenLDAP server stomps just about everything. (B) The documentation... Oh, my goodness. Can you tell it was written by a Java developer? Hell, yea. I've got an issue with lots of documentation out there but this was really bad. At a glance it still looks really bad. I suspect that if you are a Java person familiar with Tomcat / JBoss / J2EE you'll have pretty good luck with Apache DS and love the documentation. As a systems administration you wants to control LDAP, Kerberos, DNS, etc.... the documentation is an eye-bleeding nightmare. Just checking back at the site.... take look at "Configuration" under the ****User's Guide****.... the first section: "The Configuration API". Ugh. "ApacheDS provides its configuration API in the org.apache.ldap.server.configuration package. This package contains concrete configuration instruction classes that you can instantiate and specify in your JNDI environment variable. To put your configuration instruction class into the JNDI environment variable:" Uhm.... I thought the configuration section of a User's Guide would be about configuring the software? So I'd recommend OpenLDAP if all you want is an LDAP server. If you want the whole suite of services in a box then I [I cringe when I say this] recommend Windows Server 2003. It is stable, reasonably fast, and will provide everything (LDAP, DNS, KDC, DHCP, etc...) in an integrated fashion. <aside/>Yes, I can decipher Java property files, et al. But I wonder what is it about Java that makes people who write Java utterly incapable of coming back to this world and speaking English (or some other common Human tongue)? Every single Java app I'm forced to live with has simply wretched documentation followed by a thick appendix of the bleedin' API! Javadoc != documentation. Some of them are great apps but it is hard not to develop an attitude given the pervasive quality of the documentation.</aside> --- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message. -- Ersin --- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message. --- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
