directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From anto...@apache.org
Subject svn commit: r1425764 - /directory/site/trunk/content/apacheds/advanced-ug/
Date Tue, 25 Dec 2012 19:40:02 GMT
Author: antoine
Date: Tue Dec 25 19:40:02 2012
New Revision: 1425764

URL: http://svn.apache.org/viewvc?rev=1425764&view=rev
Log:
spelling and presentation changes

Modified:
    directory/site/trunk/content/apacheds/advanced-ug/1.1-architecture-overview.mdtext
    directory/site/trunk/content/apacheds/advanced-ug/1.2-network.mdtext
    directory/site/trunk/content/apacheds/advanced-ug/1.3-directory-service.mdtext
    directory/site/trunk/content/apacheds/advanced-ug/1.4-interceptors.mdtext
    directory/site/trunk/content/apacheds/advanced-ug/1.5-backend.mdtext
    directory/site/trunk/content/apacheds/advanced-ug/2-server-config.mdtext
    directory/site/trunk/content/apacheds/advanced-ug/3-admin-model.mdtext
    directory/site/trunk/content/apacheds/advanced-ug/3.1-administrative-points.mdtext

Modified: directory/site/trunk/content/apacheds/advanced-ug/1.1-architecture-overview.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/apacheds/advanced-ug/1.1-architecture-overview.mdtext?rev=1425764&r1=1425763&r2=1425764&view=diff
==============================================================================
--- directory/site/trunk/content/apacheds/advanced-ug/1.1-architecture-overview.mdtext (original)
+++ directory/site/trunk/content/apacheds/advanced-ug/1.1-architecture-overview.mdtext Tue
Dec 25 19:40:02 2012
@@ -29,9 +29,10 @@ The Apache Directory Server (aka *Apache
 ![ApacheDS architecture](images/architecture.png)
 
 As we can see, we distinguish four different layers :
-* The network
-* The Session
-* The PartitionNexus
-* The Backends
+
+* the network
+* the Session
+* the PartitionNexus
+* the Backends
 
 We will describe in detail those layers in the following chapters.
\ No newline at end of file

Modified: directory/site/trunk/content/apacheds/advanced-ug/1.2-network.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/apacheds/advanced-ug/1.2-network.mdtext?rev=1425764&r1=1425763&r2=1425764&view=diff
==============================================================================
--- directory/site/trunk/content/apacheds/advanced-ug/1.2-network.mdtext (original)
+++ directory/site/trunk/content/apacheds/advanced-ug/1.2-network.mdtext Tue Dec 25 19:40:02
2012
@@ -27,19 +27,21 @@ Notice: Licensed to the Apache Software 
 This layer is the part the user connects to when he wants to obtain some data from the server.
This is not a mandatory part ot the server : we don't need to use it when the server is embedded.
 
 We offer more than just LDAP protocol, the server also include various protocols :
+
 * Kerberos
 * NTP
 * DHCP
 * DNS
 * ChangePassword
 
-Not all of them are implemented in the current version, but at least the Kerberos server
is available. (The other protocols have been developped as a proof of concept : as they are
all dpeending on a storage database, we have used the LDAP server as a storage).
+Not all of them are implemented in the current version, but at least the Kerberos server
is available. The other protocols have been developped as a proof of concept : as they are
all depending upon a storage database, we have used the LDAP server as a storage.
 
 It's perfectly possible to imagine more protocols being implemented in the near future...
 
 ## Server startup
 
-This chapter title is a bit misleading. We don't start a server, we start a _DirectoryService_,
then we start various servers on top of it. The _DirectoryService_ is the part responsible
for the management f data (retrieval, storage, etc). All the servers can access this storage
if needed.
+This chapter title is a bit misleading. We don't start a server, we start a _DirectoryService_,
then we start various servers on top of it.
+The _DirectoryService_ is the part responsible for the management of data (retrieval, storage,
etc). All the servers can access this storage if needed.
 
 So when the _DirectoryService_ has been started and is operational, we can start the various
servers, which will accept incoming requests from remote peers.
 

Modified: directory/site/trunk/content/apacheds/advanced-ug/1.3-directory-service.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/apacheds/advanced-ug/1.3-directory-service.mdtext?rev=1425764&r1=1425763&r2=1425764&view=diff
==============================================================================
--- directory/site/trunk/content/apacheds/advanced-ug/1.3-directory-service.mdtext (original)
+++ directory/site/trunk/content/apacheds/advanced-ug/1.3-directory-service.mdtext Tue Dec
25 19:40:02 2012
@@ -28,11 +28,11 @@ The _DirectoryService_ is the core of th
 
 It has an entry point, the _OperationManager_, which is in charge of pushing the requests
into the _Interceptors_ chain, and to protect the server against concurrent modifications.
 
-Then the request is going through every _Interceptor_ being registred for this operation.
When we have gone through all the _Interceptors_, we have reach the _PartitionNexus_, which
is the connection with the backends.
+Then the request is going through every _Interceptor_ being registred for this operation.
When we have gone through all the _Interceptors_, we have reached the _PartitionNexus_, which
is the connection with the backends.
 
-We now just have to determinate which type of _Backend_ we should address, and this is done
using the _Dn_.The request is then transmitted to the _Backend_, which returns the result.
+We now just have to determinate which type of _Backend_ we should address, and this is done
using the _Dn_. The request is then transmitted to the _Backend_, which returns the result.
 
-The result bubble up through the _Interceptors_ as we unfold the stack stack, up the the
_OperationManager_ and the caller.
+The result bubbles up through the _Interceptors_ as we unfold the stack stack, up to the
_OperationManager_ and to the caller.
 
 ## Environment
 

Modified: directory/site/trunk/content/apacheds/advanced-ug/1.4-interceptors.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/apacheds/advanced-ug/1.4-interceptors.mdtext?rev=1425764&r1=1425763&r2=1425764&view=diff
==============================================================================
--- directory/site/trunk/content/apacheds/advanced-ug/1.4-interceptors.mdtext (original)
+++ directory/site/trunk/content/apacheds/advanced-ug/1.4-interceptors.mdtext Tue Dec 25 19:40:02
2012
@@ -32,29 +32,30 @@ All in all, they will handle operations 
 
 ## Handled operations
 
-Each _Interceptor_ handle a subset of the possible operations, among those listed in the
following table :
+Each _Interceptor_ handles a subset of the possible operations, among those listed in the
following table :
 
 | Operation | Description |
 |---|---|
-| Add | Add an entry in the backend |
-| Bind | Bind on the DirectoryService |
-| Compare | Compare the elements with the associated entry in the backend |
-| Delete | Delete the entry |
-| getRooDSE | Get back the RootDSE entry |
+| Add | Adds an entry in the backend |
+| Bind | Binds on the DirectoryService |
+| Compare | Compares the elements with the associated entry in the backend |
+| Delete | Deletes the entry |
+| getRooDSE | Gets back the RootDSE entry |
 | hasEntry | Tells if an entry exists |
-| Lookup | Fetch an entry |
-| Modify | Modify an entry |
-| Move | Move an entry |
-| MoveAndRename | Move and rename an entry |
-| Rename | Rename an entry |
-| Search | Search for entries |
-| Unbind | Unbind from the DirectoryService |
+| Lookup | Fetches an entry |
+| Modify | Modifies an entry |
+| Move | Moves an entry |
+| MoveAndRename | Moves and renames an entry |
+| Rename | Renames an entry |
+| Search | Searches for entries |
+| Unbind | Unbinds from the DirectoryService |
 
-It is important to understand that each operation wil go through each _Interceptor_ that
are declared to handle the operation, down to the backend.
+It is important to understand that each operation will go through each _Interceptor_ declared
to handle the operation, down to the backend.
 
 ## Existing interceptors
 
-The following interceptors are already present in the server, even if they are not enabled.
In this table, we list all the operation each interceptor is handling, and if the _interceptor_
is enabled by default or not :
+The following interceptors are already present in the server, even if they are not enabled.
+In this table, we list all the operations each interceptor is handling, and if the _interceptor_
is enabled by default or not :
 
 | Interceptor | Enabled |add|bnd|cmp|del|DSE|has|lkp|mod|mov|m&r|ren|sea|ubd|
 |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
@@ -80,7 +81,7 @@ The following interceptors are already p
 
 ## Interceptors order
 
-As we already said, the _Intecreptors_ order is significant : why would we proceed an _Add_
operation through all the _Interceptors_ if the user is simply denied the right to add an
entry by the _AciAuthorizationInterceptor_ ?
+As we already said, the _Interceptors_ order is significant : why would we proceed an _Add_
operation through all the _Interceptors_ if the user is simply denied the right to add an
entry by the _AciAuthorizationInterceptor_ ?
 
 Currently, the following order is enforced :
 
@@ -103,7 +104,7 @@ Currently, the following order is enforc
 
 ## Example
 
-Let's consider the _search_ operation. It will be processed successuvly by the following
_Intecreptors_, as it can be deduced by the two previous tables :
+Let's consider the _search_ operation. It will be processed successively by the following
_Interceptors_, as it can be deduced by the two previous tables :
 
 * NormalizationInterceptor
 * AuthenticationInterceptor
@@ -118,10 +119,10 @@ We can do the same exercise for each ope
 
 ## Processing
 
-Basically, an _Interceptor_ receives a request for an operation, do some pre-processing,
call the next _Interceptor_ in the chain, do some post-processing, and return a result. 
+Basically, an _Interceptor_ receives a request for an operation, does some pre-processing,
calls the next _Interceptor_ in the chain, does some post-processing, and returns a result.
 
 Calling the next _Interceptor_ is as simple as calling the _next(OperationContext)_ method,
which will compute the right _Interceptor_.
 
 The pre-processing and post-processing are standard Java code, there is nothing special there.

 
-Each operation is passed into an instance of a specific _OperationContext_, which contains
all what is needed about the operation and the environement.
\ No newline at end of file
+Each operation is passed into an instance of a specific _OperationContext_, which contains
all what is needed about the operation and the environment.
\ No newline at end of file

Modified: directory/site/trunk/content/apacheds/advanced-ug/1.5-backend.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/apacheds/advanced-ug/1.5-backend.mdtext?rev=1425764&r1=1425763&r2=1425764&view=diff
==============================================================================
--- directory/site/trunk/content/apacheds/advanced-ug/1.5-backend.mdtext (original)
+++ directory/site/trunk/content/apacheds/advanced-ug/1.5-backend.mdtext Tue Dec 25 19:40:02
2012
@@ -29,6 +29,7 @@ The _Backend_ is the part of the server 
 ## Existing Backends
 
 We currently have 3 different backends :
+
 * JDBM
 * LDIF
 * In-Memory
@@ -43,9 +44,9 @@ This Backend loads in memory a full set 
 
 ### LDIF Backend
 
-It come sin two forms : one single file, or many fles (one per entry). It's always backed
by a in-memory _Backend_, otherwise it would not be possible to retrieve the entries. 
+It comes in two forms : one single file, or many fles (one per entry). It's always backed
by a in-memory _Backend_, otherwise it would not be possible to retrieve the entries. 
 
-As we depend on a in-memory backend, which handles the indexes, we have to create those index
when this _Backend_ is read, which can be a costly operation. 
+As we depend on a in-memory backend, which handles the indexes, we have to create those indexes
when this _Backend_ is read, which can be a costly operation. 
 
 ### Future Backends
 
@@ -61,7 +62,7 @@ Data are stored into various tables. In 
 
 ### MasterTable
 
-The _MasterTable_ coantins all the entries, serialized. 
+The _MasterTable_ contains all the entries, serialized. 
 
 This table is a <Key, Value> **BTree**, where the key is the entry's **UUID**, and
the value the serialized entry.
 
@@ -88,11 +89,11 @@ We have 7 system indexes, which are crea
 * OneAlias : An index used for children aliases 
 * SubAlias : An index used of descendant aliases
 
-The user may define many different index, dependening on his needs.
+The user may define many different indexes, depending on his or her needs.
 
 ### The ParentIdAndRdn index
 
-This index is special, as it's used to associate an entry to a position in the **DIT**. Assuming
that each entry has a _Dn_, and that this _Dn_ describes a hierarchie, the _ParentIdAndRdn_
index depicts this hierarchy.
+This index is special, as it's used to associate an entry to a position in the **DIT**. Assuming
that each entry has a _Dn_, and that this _Dn_ describes a hierarchy, the _ParentIdAndRdn_
index depicts this hierarchy.
 
 The _ParentId_ part refers to the _UUID_ of the parent for the current entry. The _Rdn_ part
is the entry _Rdn_. In order to rebuild the full _Dn_ for a given entry, we must get all the
_ParentIdAndRdn_ up to the root to grab all the needed _Rdn_.
 

Modified: directory/site/trunk/content/apacheds/advanced-ug/2-server-config.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/apacheds/advanced-ug/2-server-config.mdtext?rev=1425764&r1=1425763&r2=1425764&view=diff
==============================================================================
--- directory/site/trunk/content/apacheds/advanced-ug/2-server-config.mdtext (original)
+++ directory/site/trunk/content/apacheds/advanced-ug/2-server-config.mdtext Tue Dec 25 19:40:02
2012
@@ -208,12 +208,12 @@ Here are the configuration parameters fo
 | dsAccessControlEnabled | ads-dsAccessControlEnabled | _boolean_  | true | Tells if the
Access Control interceptor is active |
 | dsAllowAnonymousAccess | ads-dsAllowAnonymousAccess | _boolean_  | false | Tells if the
service allow anonymous access |
 | dsDenormalizeOpAttrsEnabled | ads-dsDenormalizeOpAttrsEnabled | _boolean_  | true | Tells
if the service should denormalize operatonal attributes |
-| dsMaxPDUSize | ads-dsMaxPDUSize | _int_  | 2048 | The maximum size of an incomming PDU
(not used) |
+| dsMaxPDUSize | ads-dsMaxPDUSize | _int_  | 2048 | The maximum size of an incoming PDU (not
used) |
 | dsPasswordHidden | ads-dsPasswordHidden | _boolean_  | true | Tells if the passwords should
be encrypted (not used) |
-| dsSyncPeriodMillis | ads-dsSyncPeriodMillis | _long_  | 15000 | The delai in milliseconds
before we flush data on disk |
+| dsSyncPeriodMillis | ads-dsSyncPeriodMillis | _long_  | 15000 | The delay in milliseconds
before we flush data on disk |
 | dsTestEntries | | _String_  |  | Not used |
 | changeLog | | _ChangeLogBean_ | N/A | The interceptor that stores the reverted modifications
|
-| journal | | _JournalBean_ | N/A | The interceptor that record every modifcation |
+| journal | | _JournalBean_ | N/A | The interceptor that records every modification |
 | servers | ads-servers | _List<ServerBean>_ | N/A | The list of started servers |
 | interceptors | ads-interceptors | _List<InterceptorBean>_ | N/A | The list of interceptors
|
 | partitions | ads-partitions | _List<PartitionBean>_ | N/A | The list of existing
partitions |
@@ -263,8 +263,8 @@ The list of attributes that can be modif
 | Parameter | AttributeType | type | default value | Description |
 |---|---|---|---|---|
 | confidentialityRequired | ads-confidentialityRequired | _boolean_ |  | TODO |
-| maxSizeLimit | ads-maxSizeLimit | _int_ | 1000 | The maximum number of entries teh server
will return |
-| maxTimeLimit | ads-maxTimeLimit | _int_ | 1000 | The maimum bumber of second the server
will use to process a search request |
+| maxSizeLimit | ads-maxSizeLimit | _int_ | 1000 | The maximum number of entries the server
will return |
+| maxTimeLimit | ads-maxTimeLimit | _int_ | 1000 | The maimum number of seconds the server
will use to process a search request |
 | saslHost | ads-saslHost | _int_ |  | TODO |
 | saslPrincipal | ads-saslPrincipal | _String_ |  | TODO |
 | saslRealms | ads-saslRealms | _List<String>_ |  | TODO |

Modified: directory/site/trunk/content/apacheds/advanced-ug/3-admin-model.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/apacheds/advanced-ug/3-admin-model.mdtext?rev=1425764&r1=1425763&r2=1425764&view=diff
==============================================================================
--- directory/site/trunk/content/apacheds/advanced-ug/3-admin-model.mdtext (original)
+++ directory/site/trunk/content/apacheds/advanced-ug/3-admin-model.mdtext Tue Dec 25 19:40:02
2012
@@ -24,19 +24,22 @@ Notice: Licensed to the Apache Software 
 
 # 3 - Administrative Model
 
-The **Administrative Model** is a really critical notion that need to be understood, because
it drives many of ApacheDS roles.
+The **Administrative Model** is a really critical notion that needs to be understood, because
it drives many of ApacheDS roles.
 
 It's directly inherited by the **X.500** Administrative model (in fact, we do implement the
full **X.500** sepcification related to **AAs**).
 
 ## What is the Administrative Model ?
 
-The idea is to define the **DIT** as some areas which are administrated. Each area can be
defined, and covers a set of entries, and each area can manage one ore more roles we want
to manage. Those roles can be related to authorization, schema, etc... Each of this areas
can overlap, but in any case, if two areas are overlaping, then one area totally include the
other one. 
+The idea is to define the **DIT** as some areas which are administrated.
+Each area can be defined, and covers a set of entries, and each area can manage one ore more
roles we want to manage.
+Those roles can be related to authorization, schema, etc... Each of these areas can overlap,
but in any case, if two areas are overlapping,
+then one area totally includes the other one.
 
-The Admnistrative Model is everything we need to implement in order to be able to manage
roles on some defined areas.
+The Administrative Model is everything we need to implement in order to be able to manage
roles on some defined areas.
 
 ## Areas
 
-An Area describe a part of the **DIT** which will start from a specific entry, and span across
a part of the subtree starting at the base entry. An area is administrated by an **AP** (Administrative
Point) which holds all the needed information about the area and the roles.
+An Area describes a part of the **DIT** which will start from a specific entry, and span
across a part of the subtree starting at the base entry. An area is administrated by an **AP**
(Administrative Point) which holds all the needed information about the area and the roles.
 
 We have three kind of areas :
 
@@ -44,7 +47,7 @@ We have three kind of areas :
 * SAA : Specific Administrative Areas
 * IAA : Inner Administrative Areas
 
-**AAAs** cover all the roles as if we have declared one **SAA** for each existing role. They
overload any area in which they can be encapsulated, hiding them.
+**AAAs** cover all the roles as if we had declared one **SAA** for each existing role. They
overload any area in which they can be encapsulated, hiding them.
 
 **SAAs** cover one specific role, and overload any encapsulating area with the same role.
 
@@ -54,12 +57,13 @@ We have three kind of areas :
 
 An **Administration Point** is the point in the **DIT** where an area starts. It defines
the roles, and the scope that applies to this area.
 
-Once we know which area we need to define, and the associated roles, it's mandatory to store
those information in the **DIT**. This is done by addinga **subentries**, which just are entries
storing all the administrative configuration.
+Once we know which area we need to define, and the associated roles, it's mandatory to store
those information in the **DIT**. This is done by adding **subentries**, which just are entries
storing all the administrative configuration.
 
 An Administrative Point is stored as a **subentry** (which is just a plain LDAP entry) just
below the base of the defined area.
 
 <DIV class="info" markdown="1">
-	A **Subentry** is just a plain normal entry except that it contains administative model
informations. They are stored below the entry they are managing, as a child entry.
+	A **Subentry** is just a plain normal entry except that it contains administrative model
informations.
+	They are stored below the entry they are managing, as a child entry.
 </DIV>
 
 <DIV class="note" markdown="1">

Modified: directory/site/trunk/content/apacheds/advanced-ug/3.1-administrative-points.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/apacheds/advanced-ug/3.1-administrative-points.mdtext?rev=1425764&r1=1425763&r2=1425764&view=diff
==============================================================================
--- directory/site/trunk/content/apacheds/advanced-ug/3.1-administrative-points.mdtext (original)
+++ directory/site/trunk/content/apacheds/advanced-ug/3.1-administrative-points.mdtext Tue
Dec 25 19:40:02 2012
@@ -57,11 +57,13 @@ We will describe the types of Administra
 way they impact their associated Administrative Areas (*AA*)
 
 We have three different kind of *AP*  :
+
 * Autonomous AP ( *AAP*)
 * Specific AP (*SAP*)
 * Inner AP (*IAP*)
 
-Those three different *AP*s are related with each other in this way :
+Those three different *APs* are related with each other in this way :
+
 * *AAPs* manage an *AA* as if all the possible type of *SAP* where declared
 for this area
 * *SAPs* manage an *AA* with respect to one specific kind of role (Access
@@ -79,6 +81,7 @@ be combined with any of the above *AP*.
 
 ## Roles
 *AP* are managing some administrative aspect, defined by a role :
+
 * ACI : Manage the access control
 * CollectiveAttribute : Manage the collective attributes
 * SubSchema (not handled atm) 
@@ -88,6 +91,7 @@ be combined with any of the above *AP*.
 
 Once we have defined an *AP*, we can add some *subentries* which contain
 the description of the administrative actions, including :
+
 * The area this *subentry* covers, defined by a *SubtreeSpecification*,
 named *subtree*.
 



Mime
View raw message