svn commit: r1003845 - in /websites/staging/directory/trunk/content: ./ api/user-guide/1.3-apache-ldap-api-rational.html

[bu...@apache.org]

Author: buildbot
Date: Sat Dec 31 17:44:53 2016
New Revision: 1003845

Log:
Staging update by buildbot for directory

Modified:
    websites/staging/directory/trunk/content/   (props changed)
    websites/staging/directory/trunk/content/api/user-guide/1.3-apache-ldap-api-rational.html

Propchange: websites/staging/directory/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Sat Dec 31 17:44:53 2016
@@ -1 +1 @@
-1776803
+1776804

Modified: websites/staging/directory/trunk/content/api/user-guide/1.3-apache-ldap-api-rational.html
==============================================================================
--- websites/staging/directory/trunk/content/api/user-guide/1.3-apache-ldap-api-rational.html (original)
+++ websites/staging/directory/trunk/content/api/user-guide/1.3-apache-ldap-api-rational.html Sat Dec 31 17:44:53 2016
@@ -184,20 +184,20 @@
 }
 h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
 <h1 id="13-the-apache-ldap-api-rationale">1.3 - The Apache LDAP API rationale<a class="headerlink" href="#13-the-apache-ldap-api-rationale" title="Permanent link">&para;</a></h1>
-<p>When creating this new <strong>LDAP</strong> <strong>API</strong>, we needed to consider whether we're duplicating effort as there were already a few libraries that can do this in Java. For example:</p>
+<p>When contemplating creating a new Java API for <strong>LDAP</strong> usage, we needed to consider whether this is a duplication of effort, as there were already in existence a number of libraries. For example:</p>
 <ul>
 <li><strong>JNDI</strong> : the default <strong>JDK</strong> <strong>API</strong></li>
 <li><strong>Netscape</strong> (a.k.a Mozilla) <a href="http://www.mozilla.org/directory/javasdk.html">LdapSdk</a></li>
 <li><strong>OpenLDAP</strong> <a href="http://www.openldap.org/jldap/">JLdap</a></li>
 </ul>
-<p>So what makes the development of this new <em>LDAP JAVA API</em> a valid effort and another example of the <strong><a href="http://en.wikipedia.org/wiki/Not_Invented_Here">NIH</a></strong> syndrome?</p>
-<p>There are many reasons why we decided to start working on this <strong>API</strong> and we'll discuss them throughout this chapter.</p>
+<p>So what makes the development of our new <em>LDAP JAVA API</em> a valid effort and not another example of the <strong><a href="http://en.wikipedia.org/wiki/Not_Invented_Here">NIH</a></strong> syndrome?</p>
+<p>There are many reasons and we'll discuss them throughout this chapter.</p>
 <h2 id="history">History<a class="headerlink" href="#history" title="Permanent link">&para;</a></h2>
-<p>The Apache Directory Server project was started using the <strong>JNDI</strong> library, but many of its <strong>LDAP</strong> structure usages were developed in-house because <strong>JNDI</strong> wasn't well suited for <strong>LDAP</strong> directories.  It wasn't convenient to use JNDI (which means it won't be for you either). Eventually all of the <strong>LDAP</strong> objects (<em>Attribute</em>, <em>Entry</em>, <em>DN</em>, ...) were implemented again by us.</p>
-<p>At some point we needed to communicate with other <strong>LDAP</strong> servers without <strong>JNDI</strong>, so we developed our own <em>LdapConnection</em> class. This was the first step toward a full <strong>Java API</strong> specifically designed for LDAP usage.</p>
-<p>Strangely enough as we were doing this, back in 2007, Some people from <strong>Sun</strong> Microsystems, working on the <strong>OpenDS</strong> project, contacted us to ask if we'd be interested in helping them create the next version of <strong>JNDI</strong> (<a href="https://blogs.oracle.com/treydrake/entry/resurrecting_the_java_ldap_centric">Resurrecting The Java LDAP Centric API</a>. Sadly this effort stalled, as the need for <em>JNDI2</em> was no longer a priority for <strong>Sun</strong>. Nevertheless we decided to continue our work but the the pace was slow.</p>
-<p>The work renewed after the <strong>OpenDS</strong> project team's presentation at <strong>LdapCon</strong> in 2009 (<a href="http://www.symas.com/ldapcon2009/papers/poitou1.shtml">Towards a common LDAP API for the Java Platform</a>). The story repeated itself after <strong>Oracle</strong> bought <strong>Sun</strong> in 2010.</p>
-<p>Despite these fits and starts, a consensus was reached about the need for a new LDAP <strong>API</strong> and what it should do. We agreed on these key features for the new <strong>LDAP API</strong>:</p>
+<p>The Apache Directory Server project was started using the <strong>JNDI</strong> library, but many of its <strong>LDAP</strong> structures were developed in-house because <strong>JNDI</strong> was ineffective for interacting with <strong>LDAP</strong> directories.  It wasn't convenient for us to use JNDI.  This means it won't be for you either.  Eventually, all of the necessary <strong>LDAP</strong> data structures (<em>Attribute</em>, <em>Entry</em>, <em>DN</em>, ...) were implemented again by us.</p>
+<p>At some point we needed to communicate with other <strong>LDAP</strong> servers without using the <strong>JNDI</strong> library, so we developed our own <em>LdapConnection</em> class. This was the first step toward a full <strong>Java API</strong> specifically designed for LDAP usage on the Java platform.</p>
+<p>Strangely, after starting this effort (back in 2007), some people from <strong>Sun</strong> (Microsystems), who was working on the <strong>OpenDS</strong> project, contacted us to ask if we'd be interested in helping them create the next version of <strong>JNDI</strong>. (<a href="https://blogs.oracle.com/treydrake/entry/resurrecting_the_java_ldap_centric">Resurrecting The Java LDAP Centric API</a>. Sadly this effort stalled, as the need for <em>JNDI2</em> was no longer a priority for <strong>Sun</strong>. Nevertheless we decided to continue our work but the the pace was slow.</p>
+<p>The work renewed after the <strong>OpenDS</strong> project team's presentation at <strong>LdapCon</strong> in 2009 (<a href="http://www.symas.com/ldapcon2009/papers/poitou1.shtml">Towards a common LDAP API for the Java Platform</a>). The story repeated itself once again after <strong>Oracle</strong> bought <strong>Sun</strong> in 2010, and its project team disbanded.</p>
+<p>Despite these fits and starts, a consensus was reached about the need for a new LDAP <strong>API</strong> and what it should be capable of doing. We agreed on these key features for the new <strong>LDAP API</strong>:</p>
 <ul>
 <li>A complete coverage of the <strong>LDAP</strong> protocol</li>
 <li>A schema aware <strong>API</strong></li>
@@ -207,7 +207,7 @@ h2:hover > .headerlink, h3:hover > .head
 <h2 id="result">Result<a class="headerlink" href="#result" title="Permanent link">&para;</a></h2>
 <p>Our newly defined <strong>API</strong> fulfills all of these aspects. </p>
 <p>We needed to ensure our <strong>LDAP API</strong> was made available to the masses. Because the Apache Software Foundation values community over code, this code was the result of collaboration, and our users are a necessary part of this process.  Every time a user finds and reports a bug we have the opportunity to provide a better version of this <strong>API</strong> for everyone who uses it.</p>
-<p>In the end, we're proud to deliver a useful <strong>API</strong> that everyone can use, including our own projects like the Apache Directory Server, Directory Studio and Fortress. </p>
+<p>In the end, we're proud to deliver a useful <strong>API</strong> that everyone can use, including our sub-projects like Apache Directory Server, Apache Directory Studio, and most recently Apache Fortress. </p>
 
 
     <div class="nav">