From: Hallvard Furuseth Date: Tue, 24 Jul 2007 16:58:40 +0000 (+0000) Subject: Fix some formatting, phrasing, typos X-Git-Tag: OPENLDAP_REL_ENG_2_4_MP~295 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=9d57146b7effb1cc661643e4fe4080de4e18c8fa;p=openldap Fix some formatting, phrasing, typos --- diff --git a/doc/man/man5/slapo-dds.5 b/doc/man/man5/slapo-dds.5 index 435f368d8f..a637aa306a 100644 --- a/doc/man/man5/slapo-dds.5 +++ b/doc/man/man5/slapo-dds.5 @@ -3,7 +3,7 @@ .\" Copying restrictions apply. See the COPYRIGHT file. .\" $OpenLDAP$ .SH NAME -slapo-dds \- dds overlay +slapo-dds \- Dynamic Directory Services overlay .SH SYNOPSIS ETCDIR/slapd.conf .SH DESCRIPTION @@ -15,12 +15,13 @@ implements dynamic objects as per RFC 2589. The name .B dds stands for -Dynamic Dyrectory Services. +Dynamic Directory Services. It allows to define dynamic objects, characterized by the .B dynamicObject objectClass. -Dynamic objects have a limited life, determined by a time-to-live (TTL) -that can be refreshed by means of a specific + +Dynamic objects have a limited lifetime, determined by a time-to-live +(TTL) that can be refreshed by means of a specific .B refresh extended operation. This operation allows to set the Client Refresh Period (CRP), @@ -28,16 +29,18 @@ namely the period between refreshes that is required to preserve the dynamic object from expiration. The expiration time is computed by adding the requested TTL to the current time. -When dynamic objects reach the end of their life without being -further refreshed, they are automatically deleted; there is no guarantee -of immediate deletion, but clients should not count over it. -Dynamic objects can have subordinates, provided they also are dynamic +When dynamic objects reach the end of their lifetime without being +further refreshed, they are automatically deleted. +There is no guarantee of immediate deletion, so clients should not count +on it. + +Dynamic objects can have subordinates, provided these also are dynamic objects. -RFC 2589 does not specify what should the behavior of a dynamic -directory service be when a dynamic object with (dynamic) subordinates +RFC 2589 does not specify what the behavior of a dynamic directory +service should be when a dynamic object with (dynamic) subordinates expires. -In this implementation, the life of dynamic objects with subordinates -is prolonged until all the dynamic subordinates expired. +In this implementation, the lifetime of dynamic objects with subordinates +is prolonged until all the dynamic subordinates expire. This @@ -61,7 +64,7 @@ and operations. Since its use may result in many internal entry lookups, adds and deletes, it should be best used in conjunction with backends -that have resonably good write performances. +that have reasonably good write performances. .LP The config directives that are specific to the @@ -73,19 +76,20 @@ database or to other stacked overlays. .TP .B dds\-max\-ttl -Specifies the max TTL value; this is the default TTL newly created +Specifies the max TTL value. +This is also the default TTL newly created dynamic objects receive, unless .B dds\-default\-ttl is set. -When the client with a refresh exop requests a TTL higher than it, -sizeLimitExceeded is returned. +When the client with a refresh extended operation requests a TTL higher +than it, sizeLimitExceeded is returned. This value must be between 86400 (1 day, the default) and 31557600 (1 year plus 6 hours, as per RFC 2589). .TP .B dds\-min\-ttl Specifies the min TTL value; clients requesting a lower TTL by means -of the refresh exop actually obtain this value as CRP. +of the refresh extended operation actually obtain this value as CRP. If set to 0 (the default), no lower limit is set. .TP @@ -103,11 +107,12 @@ Specifies the interval between expiration checks; defaults to 1 hour. .B dds\-tolerance Specifies an extra time that is added to the timer that actually wakes up the thread that will delete an expired dynamic object. -So the nominal life of the entry is that specified in the +So the nominal lifetime of the entry is that specified in the .B entryTtl -attribute, but its life will actually be -.BR " entryTtl + tolerance " . -Note that there is no guarantee that the life of a dynamic object will be +attribute, but its lifetime will actually be +.BR "entryTtl + tolerance" . +Note that there is no guarantee that the lifetime of a dynamic object +will be .I exactly the requested TTL; due to implementation details, it may be longer, which is allowed by RFC 2589. @@ -117,8 +122,8 @@ By default, tolerance is 0. .B dds\-max\-dynamicObjects Specifies the maximum number of dynamic objects that can simultaneously exist within a naming context. -This allows to limit the amount of resources (mostly in terms of runqueue size) -that are used by dynamic objects. +This allows to limit the amount of resources (mostly in terms of +run-queue size) that are used by dynamic objects. By default, no limit is set. .TP @@ -146,8 +151,8 @@ is an operational, NO-USER-MODIFICATION attribute, no direct write access to it is possible. So the .B dds -overlay turns refresh exops into an internal modification to the value -of the +overlay turns refresh extended operation into an internal modification to +the value of the .B entryTtl attribute with the .B manageDIT