Parcourir la 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 il y a 15 ans
Parent
commit
b2de234050
1 fichiers modifiés avec 25 ajouts et 6 suppressions
  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
 (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++.