directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From elecha...@apache.org
Subject svn commit: r1415895 - in /directory/site/trunk/content/api: user-guide.mdtext user-guide/1.1-java-and-ldap.mdtext user-guide/1.3-apache-ldap-api-rational.mdtext
Date Sat, 01 Dec 2012 00:25:43 GMT
Author: elecharny
Date: Sat Dec  1 00:25:42 2012
New Revision: 1415895

URL: http://svn.apache.org/viewvc?rev=1415895&view=rev
Log:
Fixed the lists

Modified:
    directory/site/trunk/content/api/user-guide.mdtext
    directory/site/trunk/content/api/user-guide/1.1-java-and-ldap.mdtext
    directory/site/trunk/content/api/user-guide/1.3-apache-ldap-api-rational.mdtext

Modified: directory/site/trunk/content/api/user-guide.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/api/user-guide.mdtext?rev=1415895&r1=1415894&r2=1415895&view=diff
==============================================================================
--- directory/site/trunk/content/api/user-guide.mdtext (original)
+++ directory/site/trunk/content/api/user-guide.mdtext Sat Dec  1 00:25:42 2012
@@ -45,11 +45,11 @@ We are quite interested to improve the c
 
 ### Table of contents
 
-* [1 - Introduction](user-guide/1-introduction.html)
-  *  [1.1 - Java and LDAP](user-guide/1.1-java-and-ldap.html)
-  *  [1.2 - LDAP in a few words](user-guide/1.2-ldap-in-a-few-words.html)
-  *  [1.3 - The Apache LDAP API rational](user-guide/1.3-apache-ldap-api-rational.html)
-  *  [1.4 - Preparation to code](user-guide/1.4-preparation-to-code.html)
+    * [1 - Introduction](user-guide/1-introduction.html)
+        *  [1.1 - Java and LDAP](user-guide/1.1-java-and-ldap.html)
+        *  [1.2 - LDAP in a few words](user-guide/1.2-ldap-in-a-few-words.html)
+        *  [1.3 - The Apache LDAP API rational](user-guide/1.3-apache-ldap-api-rational.html)
+        *  [1.4 - Preparation to code](user-guide/1.4-preparation-to-code.html)
 
 Basic LDAP API usage (...)
 

Modified: directory/site/trunk/content/api/user-guide/1.1-java-and-ldap.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/api/user-guide/1.1-java-and-ldap.mdtext?rev=1415895&r1=1415894&r2=1415895&view=diff
==============================================================================
--- directory/site/trunk/content/api/user-guide/1.1-java-and-ldap.mdtext (original)
+++ directory/site/trunk/content/api/user-guide/1.1-java-and-ldap.mdtext Sat Dec  1 00:25:42
2012
@@ -31,13 +31,13 @@ Those two facts make it necessary to be 
 
 Of course, there are alternatives, like JNDI. We truly believe that those alternative aren't
helping users to cope with the complexity of LDAP, at least they are not giving a hand to
users. For instance, JNDI semantic are far awy from *LDAP semantic. Let's see how different
it is :
 
-    * Bind : used in LDAP to authenticate a user, and to create an entry in JNDI
-    * Unbind : close the LDAP session in LDAP, delete an entry in JNDI
-    * Compare : this LDAP operation is mapped to a Search in JNDI
-    * Various properties have to be set in JNDI in order to connect or tweak the Search operation,
which is not convenient
-    * Attributes is case sensitive by default in JNDI, and they aren't schema aware
-    * Name in JNDI are not able to do a valid comparison in JNDI
-    * NamingEnumeration have to be explcitly closed in JNDI, as they aren't closed when you
disconnect, leading to some resource leaks.
+* Bind : used in LDAP to authenticate a user, and to create an entry in JNDI
+* Unbind : close the LDAP session in LDAP, delete an entry in JNDI
+* Compare : this LDAP operation is mapped to a Search in JNDI
+* Various properties have to be set in JNDI in order to connect or tweak the Search operation,
which is not convenient
+* Attributes is case sensitive by default in JNDI, and they aren't schema aware
+* Name in JNDI are not able to do a valid comparison in JNDI
+* NamingEnumeration have to be explcitly closed in JNDI, as they aren't closed when you disconnect,
leading to some resource leaks.
 
 Some of those problems are also true for the existing LDAP API.
 

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=1415895&r1=1415894&r2=1415895&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
 1 00:25:42 2012
@@ -26,9 +26,9 @@ Notice: Licensed to the Apache Software 
 
 Once we start to think about creating a new **LDAP** **API**, the first thing that comes
to mind is that it could be a duplication of effort : there are already many libraries offering
almost everything needed to write **LDAP** code. Some of them are :
 
-    * **JNDI** : the default **JDK** **API**
-    * **Netscape** [LdapSdk](http://www.mozilla.org/directory/javasdk.html)
-    * **OpenLDAP** [JLdap](http://www.openldap.org/jldap/)
+* **JNDI** : the default **JDK** **API**
+* **Netscape** [LdapSdk](http://www.mozilla.org/directory/javasdk.html)
+* **OpenLDAP** [JLdap](http://www.openldap.org/jldap/)
 
 So what makes the development of a new *LDAP JAVA API* a valid effort, and not another version
of **[NIH](http://en.wikipedia.org/wiki/Not_Invented_Here)** syndrom ?
 
@@ -45,10 +45,10 @@ We started again to work on this API wit
 
 At least, we get some kind of convergence in many aspects of the **API**. We agreed on some
of the key features the new **LDAP API** should offer :
 
-    * A complete coverage of the **LDAP** protocol
-    * A schema aware **API**
-    * An easy to use **API**
-    * An **API** taking advantage of the new **Java** construction (generics, ellipsis, NIO)
+* A complete coverage of the **LDAP** protocol
+* A schema aware **API**
+* An easy to use **API**
+* An **API** taking advantage of the new **Java** construction (generics, ellipsis, NIO)
 
 ## Result
 The newly defined **API** fulfill all those aspects. 



Mime
View raw message