BIND 10 #2157: Create an interface to pass statistics counters in Auth module

[BIND 10 Development]

#2157: Create an interface to pass statistics counters in Auth module
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  y-aharen                           |                Status:  reviewing
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20121106
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:         |           Sub-Project:  DNS
  b10-auth                           |  Estimated Difficulty:  8
                   Keywords:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:24 y-aharen]:

 > > Hardcoding the conversion as a near term compromise is okay.  What I'm
 > > not convinced is to hardcode the particular RR types in places like
 > > auth.spec or `QRQTypeToQRCounterType`.
 > There is no way to avoid enumerating items in auth.spec in current Stats
 design.
 > I think we can solve it with some kind of auto-generation of spec file
 and QRQTypeToQRCounterType. However, current implementation of libdns++
 lacks some rrtypes. I'd like to do it in another ticket with design
 consideration if possible, this ticket lives quite longer.

 I'm sorry for being stubborn, but I'm still not convinced.  This time
 I took a little bit deeper look at the branch and the stats
 implementation, but I don't understand what's the fundamental design
 limitation of Stats that requires the hardcoded specific RR types in
 auth.spec.  For example, can't it be a named set?

 I don't like to keep holding this feature too long either, but I'm
 afraid this is probably one of the cases where if we make an easy
 compromise in the first stage that will become a precedent that makes
 us very reluctant to make it cleaner later (and as a result we'll end
 up living with the suboptimal design and suffering from maintenance
 pains for a longer period).  So, unless I'm convinced it's really
 impossible without touching a very fundamental part of the entire
 architecture, I don't like to make a compromise here to move forward.

 One possibility is to exclude per-RR type counters at this time and
 have a separate discussion on how to implement such parameterized
 statistics counters.  If possible I'd like to avoid that, however,
 because essentially the same discussion should apply to per-opcode and
 per-rcode counters and this is our opportunity to revise the design
 for these, too.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2157#comment:25>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development