From 97676d5d595a8c9ae1d37f449bef87daf2d9f306 Mon Sep 17 00:00:00 2001
From: Quanah Gibson-Mount <quanah@openldap.org>
Date: Mon, 14 Apr 2008 21:00:49 +0000
Subject: [PATCH] Encoding on backends.sdf and More work on Overlays.

---
 doc/guide/admin/backends.sdf |  2 +-
 doc/guide/admin/overlays.sdf | 62 ++++++++++++++++++++++++++++++++----
 2 files changed, 57 insertions(+), 7 deletions(-)

diff --git a/doc/guide/admin/backends.sdf b/doc/guide/admin/backends.sdf
index c594c82387..1d4a2e17b7 100644
--- a/doc/guide/admin/backends.sdf
+++ b/doc/guide/admin/backends.sdf
@@ -44,7 +44,7 @@ Sessions that explicitly {{Bind}} to the {{back-ldap}} database always create
 their own private connection to the remote LDAP server. Anonymous sessions 
 will share a single anonymous connection to the remote server. For sessions 
 bound through other mechanisms, all sessions with the same DN will share the 
-same connection. This connection pooling strategy can enhance the proxy’s 
+same connection. This connection pooling strategy can enhance the proxy's 
 efficiency by reducing the overhead of repeatedly making/breaking multiple 
 connections.
 
diff --git a/doc/guide/admin/overlays.sdf b/doc/guide/admin/overlays.sdf
index d49586c636..e12f5d732b 100644
--- a/doc/guide/admin/overlays.sdf
+++ b/doc/guide/admin/overlays.sdf
@@ -360,14 +360,64 @@ 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 the behavior of a dynamic directory service 
-should be when a dynamic object with (dynamic) subordinates expires.
-In this implementation, the lifetime of dynamic objects with subordinates is prolonged
-until all the dynamic subordinates expire.
-   
 H3: Dynamic Directory Service Configuration
 
+A usage of dynamic objects might beto implement dynamic meetings; in this case, 
+all the participants to the meeting are allowed to refresh the meeting object, 
+but only the creator can delete it (otherwise it will be deleted when the TTL expires).
+
+If we add the overlay to an example database, specifying a Max TTL of 1 day, a 
+min of 10 seconds, with a default TTL of 1 hour. We'll also specify an interval
+of 5 seconds between expiration checks and a tolerance of 1 second (lifetime of
+a dynamic object will be {{B:entryTtl + tolerance}}.
+
+>       overlay dds
+>       dds-max-ttl     1d
+>       dds-min-ttl     10s
+>       dds-default-ttl 1h
+>       dds-interval    5s
+>       dds-tolerance   1s
+
+So let's create an entry using:
+
+>       dn: cn=Dynamic,dc=example,dc=com
+>       objectClass: inetOrgPerson
+>       objectClass: dynamicObject
+>       cn: Dynamic Object
+>       sn: Object
+
+MORE coming.
+
+
+H4: Dynamic Directory Service ACLs
+
+Allow users to start a meeting and to join it; restrict refresh to the {{B:member}}s; 
+restrict delete to the creator:
+
+>       access to attrs=userPassword
+>          by self write
+>          by * read
+>       
+>       access to dn.base="cn=Meetings,dc=example,dc=com"
+>                 attrs=children
+>            by users write
+>       
+>       access to dn.onelevel="cn=Meetings,dc=example,dc=com"
+>                 attrs=entry
+>            by dnattr=creatorsName write
+>            by * read
+>       
+>       access to dn.onelevel="cn=Meetings,dc=example,dc=com"
+>                 attrs=participant
+>            by dnattr=creatorsName write
+>            by users selfwrite
+>            by * read
+>       
+>       access to dn.onelevel="cn=Meetings,dc=example,dc=com"
+>                 attrs=entryTtl
+>            by dnattr=member manage
+>            by * read
+
 
 H2: Dynamic Groups
 
-- 
2.39.5