[svn] commit: r2539 - /branches/trac256/src/lib/dns/util/README

[BIND 10 source code commits]

Author: jinmei
Date: Tue Jul 20 06:11:13 2010
New Revision: 2539

Log:
review comment: describe why the interfaces under util should be hidden.

Modified:
    branches/trac256/src/lib/dns/util/README

Modified: branches/trac256/src/lib/dns/util/README
==============================================================================
--- branches/trac256/src/lib/dns/util/README (original)
+++ branches/trac256/src/lib/dns/util/README Tue Jul 20 06:11:13 2010
@@ -2,11 +2,30 @@
 implementations that are internally used in the DNS library
 (libdns++).
 
-The header files in this directory are not intended to be installed.
-Likewise, classes and public functions defined in this directory are
-not intended to be used outside libdns++, although we cannot prohibit
-it at the language level.
+The functionality provided in these tools is generally available in
+other external or perhaps system supplied libraries.  The basic
+development policy of BIND 10 is to avoid "reinventing wheels" unless
+they belong to the exact technology area that BIND 10 targets (e.g.,
+DNS).  However, libdns++ is a very core part of BIND 10, and is also
+intended to be used as a public library, so dependency from libdns++
+to external libraries should be minimized.  The utilities in this
+directory are provided balancing two policies and as a kind of
+compromise.
+
+The header files in this directory are therefore not intended to be
+installed.  Likewise, classes and public functions defined in this
+directory are not intended to be used outside libdns++, although we
+cannot prohibit it at the language level.
 
 They are not even expected to be used in other modules of BIND 10 than
-libdns++.  Although there seem to be some violations as of this
-writing, we should eventually fix it.
+libdns++ based on the basic policy explained above.  Other modules
+should only rely on the DNS specific interface that may internally
+rely on these utility interfaces, or should use external libraries if
+the other module really needs to use the utility feature directly.
+There seem to be some violations as of this writing, but we should
+eventually fix it.  A notable example is the SHA1 interfaces.  They
+are defined here in the context of NSEC3 processing, but, in fact,
+they are not even used from any of the other libdns++ classes or
+functions.  The SHA1 related interfaces should be moved to the
+application that needs it or the application should only access it
+through DNS specific interfaces defined in libdns++.