svn commit: r1776669 - in /directory/site/trunk/content/api/user-guide: 1.2-ldap-in-a-few-words.mdtext 1.3-apache-ldap-api-rational.mdtext

[sm...@apache.org]

Author: smckinney
Date: Sat Dec 31 00:54:27 2016
New Revision: 1776669

URL: http://svn.apache.org/viewvc?rev=1776669&view=rev
Log:
mroe 

Modified:
    directory/site/trunk/content/api/user-guide/1.2-ldap-in-a-few-words.mdtext
    directory/site/trunk/content/api/user-guide/1.3-apache-ldap-api-rational.mdtext

Modified: directory/site/trunk/content/api/user-guide/1.2-ldap-in-a-few-words.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/api/user-guide/1.2-ldap-in-a-few-words.mdtext?rev=1776669&r1=1776668&r2=1776669&view=diff
==============================================================================
--- directory/site/trunk/content/api/user-guide/1.2-ldap-in-a-few-words.mdtext (original)
+++ directory/site/trunk/content/api/user-guide/1.2-ldap-in-a-few-words.mdtext Sat Dec 31 00:54:27 2016
@@ -4,7 +4,7 @@ NavPrevText: 1.1 - Java and LDAP
 NavUp: 1-introduction.html
 NavUpText: 1 - Introduction
 NavNext: 1.3-apache-ldap-api-rational.html
-NavNextText: 1.3 - The Apache LDAP API rational
+NavNextText: 1.3 - The Apache LDAP API rationale
 Notice: Licensed to the Apache Software Foundation (ASF) under one
     or more contributor license agreements.  See the NOTICE file
     distributed with this work for additional information

Modified: directory/site/trunk/content/api/user-guide/1.3-apache-ldap-api-rational.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/api/user-guide/1.3-apache-ldap-api-rational.mdtext?rev=1776669&r1=1776668&r2=1776669&view=diff
==============================================================================
--- directory/site/trunk/content/api/user-guide/1.3-apache-ldap-api-rational.mdtext (original)
+++ directory/site/trunk/content/api/user-guide/1.3-apache-ldap-api-rational.mdtext Sat Dec 31 00:54:27 2016
@@ -24,26 +24,26 @@ Notice: Licensed to the Apache Software
 
 # 1.3 - The Apache LDAP API rationale
 
-When creating a new **LDAP** **API**, we need to consider whether it's a duplication of effort; there are already some libraries that do this. For example:
+When creating this new **LDAP** **API**, we needed to consider whether we're duplicating effort as there were already a few libraries that can do this in Java. For example:
 
 * **JNDI** : the default **JDK** **API**
 * **Netscape** (a.k.a Mozilla) [LdapSdk](http://www.mozilla.org/directory/javasdk.html)
 * **OpenLDAP** [JLdap](http://www.openldap.org/jldap/)
 
-What makes the development of this new *LDAP JAVA API* a valid effort, and **[NIH](http://en.wikipedia.org/wiki/Not_Invented_Here)** syndrom?
+So what makes the development of this new *LDAP JAVA API* a valid effort and another example of the **[NIH](http://en.wikipedia.org/wiki/Not_Invented_Here)** syndrome?
 
-There are many reasons why we decided to start to work on this **API**, and we'll discuss them throughout this chapter.
+There are many reasons why we decided to start working on this **API** and we'll discuss them throughout this chapter.
 
 ## History
-The Apache Directory Server project was first using **JNDI**, but many of the internal **LDAP** structures were developed internally, because **JNDI** was not well suited for **LDAP** usage.  This meant it wasn't convenient for us to use these structures. Step by step, all of the **LDAP** objects (_Attribute_, _Entry_, _DN_, ...) were implemented again.
+The Apache Directory Server project was started using the **JNDI** library, but many of its **LDAP** structure usages were developed in-house because **JNDI** wasn't well suited for **LDAP** directories.  It wasn't convenient to use JNDI (which means it won't be for you either). Eventually all of the **LDAP** objects (_Attribute_, _Entry_, _DN_, ...) were implemented again by us.
 
-At some point, we needed to communicate with other **LDAP** servers without having using **JNDI**, so we developed our own _LdapConnection_ class. This was the first step toward a full **Java API** specifically designed for LDAP.
+At some point we needed to communicate with other **LDAP** servers without **JNDI**, so we developed our own _LdapConnection_ class. This was the first step toward a full **Java API** specifically designed for LDAP usage.
 
-Strangely enough when we were doing this, back in 2007, **Sun** people working on the **OpenDS** project contacted us to ask if we'd be interested in helping them with the next version of **JNDI** ([Resurrecting The Java LDAP Centric API](https://blogs.oracle.com/treydrake/entry/resurrecting_the_java_ldap_centric). Sadly, this effort stalled, as the need for *JNDI2* was no longer a priority for **Sun**. We decided to continue with our work but the the pace was slow.
+Strangely enough as we were doing this, back in 2007, Some people from **Sun** Microsystems, working on the **OpenDS** project, contacted us to ask if we'd be interested in helping them create the next version of **JNDI** ([Resurrecting The Java LDAP Centric API](https://blogs.oracle.com/treydrake/entry/resurrecting_the_java_ldap_centric). Sadly this effort stalled, as the need for *JNDI2* was no longer a priority for **Sun**. Nevertheless we decided to continue our work but the the pace was slow.
 
-The work began once again after the **OpenDS** project team's presentation at **LdapCon** back in 2009 ([Towards a common LDAP API for the Java Platform](http://www.symas.com/ldapcon2009/papers/poitou1.shtml)). The story repeated itself after **Oracle** bought **Sun** in 2010.
+The work renewed after the **OpenDS** project team's presentation at **LdapCon** in 2009 ([Towards a common LDAP API for the Java Platform](http://www.symas.com/ldapcon2009/papers/poitou1.shtml)). The story repeated itself after **Oracle** bought **Sun** in 2010.
 
-Despite these fits and starts, a consensus was reached on the need for a new **API** and what it should do. We agreed on the key features for a new **LDAP API**:
+Despite these fits and starts, a consensus was reached about the need for a new LDAP **API** and what it should do. We agreed on these key features for the new **LDAP API**:
 
 * A complete coverage of the **LDAP** protocol
 * A schema aware **API**
@@ -51,8 +51,8 @@ Despite these fits and starts, a consens
 * An **API** taking advantage of the new **Java** construction (generics, ellipsis, NIO)
 
 ## Result
-This newly defined **API** fulfills all of these aspects. 
+Our newly defined **API** fulfills all of these aspects. 
 
-We wanted to make sure this **API** was made available to the masses. The Apache Software Foundation values quality and community over code, which means the code is the result of a collaborative work, our users being a necessary part of this collaboration. Every bug a user finds, is an opportunity to provide a better version of the **API** for everyone.
+We needed to ensure our **LDAP API** 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 **API** for everyone who uses it.
 
-In the end, we're proud to deliver a useful **API** that everyone can use, include our own projects like the Apache Directory Server, Directory Studio and Fortress. 
+In the end, we're proud to deliver a useful **API** that everyone can use, including our own projects like the Apache Directory Server, Directory Studio and Fortress.