alias_db(k): rephrase documentation a bit to make it hopefully better understandable
authorHenning Westerholt <henning.westerholt@1und1.de>
Wed, 27 Jul 2011 15:29:14 +0000 (17:29 +0200)
committerHenning Westerholt <henning.westerholt@1und1.de>
Wed, 27 Jul 2011 15:29:14 +0000 (17:29 +0200)
modules_k/alias_db/README
modules_k/alias_db/doc/alias_db_admin.xml

index 8c18133..33743d4 100644 (file)
@@ -83,15 +83,17 @@ Chapter 1. Admin Guide
 
 1. Overview
 
-   ALIAS_DB module can be used as an alternative for user aliases via
+   The ALIAS_DB module can be used as an alternative for user aliases via
    usrloc. The main feature is that it does not store all addiacent data
-   as for user location and always uses database for search (no memory
-   caching).
-
-   Having no memory caching the speed of search can decrease but the
-   provisioning is easier. With very fast databases like MySQL the speed
-   penalty can be lowered. Also, the search can be performed on different
-   tables in the same script.
+   as for user location and always uses the database for search (no memory
+   caching). A common use case is to provide additional user aliases, i.e.
+   to supplement the registration in the location database. Users are this
+   way on a proxy reachable with several request URIs.
+
+   As the module use no memory caching the lookup is a bit slower but the
+   data provisioning is easier. With very fast databases like MySQL the
+   speed penalty can be lowered. Also, the search can be performed on
+   different tables in the same script.
 
 2. Dependencies
 
index 1e662b5..02b2913 100644 (file)
        <section>
        <title>Overview</title>
        <para>
-       ALIAS_DB module can be used as an alternative for user aliases
+       The ALIAS_DB module can be used as an alternative for user aliases
        via usrloc. The main feature is that it does not store all addiacent
-       data as for user location and always uses database for search (no
-       memory caching).
+       data as for user location and always uses the database for search (no
+       memory caching). A common use case is to provide additional user
+       aliases, i.e. to supplement the registration in the location database.
+       Users are this way on a proxy reachable with several request URIs.
        </para>
        <para>
-       Having no memory caching the speed of search can decrease but the
-       provisioning is easier. With very fast databases like MySQL the speed
+       As the module use no memory caching the lookup is a bit slower but the
+       data provisioning is easier. With very fast databases like MySQL the speed
        penalty can be lowered. Also, the search can be performed on different
        tables in the same script.
        </para>