Browse Source

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

git-svn-id: svn://bind10.isc.org/svn/bind10/branches/trac256@2539 e5f2f494-b856-4b98-b285-d166d9295462
JINMEI Tatuya 15 years ago
parent
commit
b2de234050
1 changed files with 25 additions and 6 deletions
  1. 25 6
      src/lib/dns/util/README

+ 25 - 6
src/lib/dns/util/README

@@ -2,11 +2,30 @@ This "util" directory is provided for utility header files and
 implementations that are internally used in the DNS library
 implementations that are internally used in the DNS library
 (libdns++).
 (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
 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++.