- notes on what's been implemented

1 files changed, 35 insertions, 36 deletions

diff --git a/doc/design.txt b/doc/design.txt
index b7301f8..41c8be1 100644
--- a/doc/design.txt
+++ b/doc/design.txt
@@ -152,13 +152,13 @@ alternate approach of performing an LDAP query for each NIS query:
 
 The backend interface module sets up, populates, and maintains the map
 cache.  At startup time, it configures the map cache with the list of
-domains and maps, and populates the maps with initial data.  [Using
+domains and maps, and populates the maps with initial data.  Using
 postoperation plugin hooks, the backend interface also notes when
 entries are added, modified, renamed (modrdn'd), or deleted from the
-directory server.  It uses this information to create or destroy maps in
-the map cache, and to add, remove, or update entries in the map cache's
+directory server.  It uses this information to [create or destroy maps in
+the map cache, and to] add, remove, or update entries in the map cache's
 maps, thereby ensuring that the map cache always reflects the current
-contents of the directory server.]
+contents of the directory server.
 
 The backend interface reads the configuration it should use for the map
 cache from its configuration area in the directory server.  Beneath the
@@ -167,47 +167,46 @@ plugin's entry, the backend checks for entries with these attributes:
  * map
  * base
  * filter
- * key[Attribute]
+ * key[Format]
  * value[Format]
 The backend then instructs the map cache to prepare to hold a map in the
 given domain with the given map name, and then performs a subtree search
 under the specified base for entries which match the provided filter.
 Each found entry is then "added" to the map, using the value of the
-attribute named by the "key[Attribute]" as the key for the entry in the
+attribute named by the "key[Format]" as the key for the entry in the
 map, with the corresponding value in the map being the value of the
 attribute named by the "value" [being constructed using the format
 specifier given as the "valueFormat"].
 
-[The "valueFormat" specifier resembles an RPM format specifier, and can
- include the values of multiple attributes in any part of the specifier.
- The backend composes the string using the attribute values stored in
- the directory server entry, using the format specifier as a guide.  In
- this way, the NIS map's contents can be constructed to almost any
- specification, can make use of data stored using any schema.  (That's
- the plan, anyway.)
-
- An example specification for a user's entry would look like this:
-   %{uid}:%{userPassword:-*}:%{uidNumber}:%{gidNumber}:%{gecos:-%{cn:-}}:%{homeDirectory}:%{loginShell:-/bin/sh}
- The syntax borrows from RPM's syntax, which in turn borrows from shell
- syntax, to allow the specification of alternate values to be used when
- the directory server entry doesn't include a "userPassword" or "gecos"
- attribute.
-
- To ensure safety, any reference to an attribute value which does not
- also specify an alternate value will cause the directory server entry
- to be ignored if the referenced attribute has no value defined for that
- entry, or contains multiple values.  In the above example, the entry
- would be ignored if the "uid", "uidNumber", "gidNumber", or
- "homeDirectory" attributes of the entry did not each contain exactly
- one value.
- 
- The syntax further defines "functions" which can be used to concatenate
- lists of multiple values into a single result, for example for groups:
-   %{cn}:%{userPassword:-*}:%{gidNumber}:%merge{",","memberUid"})
- This filter takes advantage of a built-in "merge" function, which
- processes zero or more values of the "memberUid" attribute and
- concatenates them together with a "," separator, to generate the list
- of group members.]
+The "valueFormat" specifier resembles an RPM format specifier, and can
+include the values of multiple attributes in any part of the specifier.
+The backend composes the string using the attribute values stored in
+the directory server entry, using the format specifier as a guide.  In
+this way, the NIS map's contents can be constructed to almost any
+specification, can make use of data stored using any schema.
+
+An example specification for a user's entry would look like this:
+  %{uid}:%{userPassword:-*}:%{uidNumber}:%{gidNumber}:%{gecos:-%{cn:-}}:%{homeDirectory}:%{loginShell:-/bin/sh}
+The syntax borrows from RPM's syntax, which in turn borrows from shell
+syntax, to allow the specification of alternate values to be used when
+the directory server entry doesn't include a "userPassword" or "gecos"
+attribute.
+
+To ensure safety, any reference to an attribute value which does not
+also specify an alternate value will cause the directory server entry
+to be ignored if the referenced attribute has no value defined for that
+entry, or contains multiple values.  In the above example, the entry
+would be ignored if the "uid", "uidNumber", "gidNumber", or
+"homeDirectory" attributes of the entry did not each contain exactly
+one value.
+
+The syntax further defines "functions" which can be used to concatenate
+lists of multiple values into a single result, for example for groups:
+  %{cn}:%{userPassword:-*}:%{gidNumber}:%list{",","memberUid"})
+This filter takes advantage of a built-in "list" function, which
+processes zero or more values of the "memberUid" attribute and
+concatenates them together with a "," separator, to generate the list
+of group members.
 
 [The filter, key, and value have sensible defaults for the maps which we
  expect to be using -- this is important because it's easy to subtly