svn commit: r1003857 - in /websites/staging/directory/trunk/content: ./ api/user-guide/1.2-ldap-in-a-few-words.html api/user-guide/1.3-apache-ldap-api-rational.html

[bu...@apache.org]

Author: buildbot
Date: Sun Jan  1 00:18:52 2017
New Revision: 1003857

Log:
Staging update by buildbot for directory

Modified:
    websites/staging/directory/trunk/content/   (props changed)
    websites/staging/directory/trunk/content/api/user-guide/1.2-ldap-in-a-few-words.html
    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 Sun Jan  1 00:18:52 2017
@@ -1 +1 @@
-1776810
+1776821

Modified: websites/staging/directory/trunk/content/api/user-guide/1.2-ldap-in-a-few-words.html
==============================================================================
--- websites/staging/directory/trunk/content/api/user-guide/1.2-ldap-in-a-few-words.html (original)
+++ websites/staging/directory/trunk/content/api/user-guide/1.2-ldap-in-a-few-words.html Sun Jan  1 00:18:52 2017
@@ -187,7 +187,7 @@ h2:hover > .headerlink, h3:hover > .head
 <p><strong>LDAP</strong> is not a new technlology. It has been around since the 90's to mitigate complexities inherent in <strong>X.500</strong> usage. Its name refers to <strong>L</strong>ightweight <strong>D</strong>irectory <strong>A</strong>ccess <strong>P</strong>rotocol. Soon after the first standard was issued, the first full <em>LDAP</em> server was created and X.500 became obsolete.</p>
 <p>We'll use the term <strong>LDAP</strong> to represent the protocol and <strong>LDAP server</strong> to represent the server that implements it.</p>
 <h2 id="features">Features<a class="headerlink" href="#features" title="Permanent link">&para;</a></h2>
-<p>The <strong>LDAP</strong> protocol provides access to entries stored in a <strong>LDAP Server's</strong> database. It provides the mechanism for fast searching and retrieval of entries. Its data structures are hierarchical, and uses a schema to manage the definition of data formats allowed accross those entries.</p>
+<p>The <strong>LDAP</strong> protocol provides access to entries stored in a <strong>LDAP Server's</strong> database. It provides the mechanism for fast searching and retrieval of entries. Its data structures are hierarchical, and uses a schema to manage the definition of data formats allowed across those entries.</p>
 <p>An <strong>LDAP</strong> client must first connect to a server and disconnect when finished. Some operations may be performed on the data itself, e.g. searches, modifications and deletions, along with a few others.</p>
 <p><strong>LDAP</strong> servers are extensible, but they all use a common protocol providing access to the data in a way that isn't tied to a particular vendor's implementation.</p>
 <h2 id="characteristics">Characteristics<a class="headerlink" href="#characteristics" title="Permanent link">&para;</a></h2>

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 Sun Jan  1 00:18:52 2017
@@ -184,17 +184,17 @@
 }
 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 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>
+<p>When contemplating the creation of a new Java API for <strong>LDAP</strong>, we needed to first consider whether it was really necessary, because there were already a number of libraries that did it. 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-archive.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 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>
+<p>So why is the development of our new <em>LDAP API</em> for Java NOT the <strong><a href="http://en.wikipedia.org/wiki/Not_Invented_Here">NIH</a></strong> syndrome?</p>
+<p>There are a number of reasons for which we'll discuss 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> 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 which 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>The Apache Directory Server project was started using the <strong>JNDI</strong> library, but many of its <strong>LDAP</strong> structures had to be developed in-house because the <strong>JNDI</strong> library was ineffective for interacting with an <strong>LDAP</strong> server.  It wasn't convenient for us to use JNDI which 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 re-implemented by us.</p>
+<p>At some point we had 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>