BIND 10 #2225: Implement counters into Xfrout (3/3)

BIND 10 Development do-not-reply at isc.org
Tue Nov 20 10:27:16 UTC 2012


#2225: Implement counters into Xfrout (3/3)
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  naokikambe                         |                Status:  reviewing
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20121120
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:         |           Sub-Project:  DNS
  xfrout                             |  Estimated Difficulty:  7
                   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:15 naokikambe]:
 > After I'm given your comments, I've realized as the followings. Is this
 correct?

 In general, yes.

 > - We may implement an abstract counter class under isc.statistics.
 > - We shouldn't implement a concrete counter class, e.g.
 ``!XfroutCounter``, for a specific module under isc.statistics.

 Maybe "shouldn't" sounds too strong, but it just looked too awkward to
 me to have such things as `XfroutCounter` in the isc.statistics package.

 > - We may implement such a concrete counter class in the module, e.g.
 ``b10-xfrout.py``, which uses it.

 Or at the very least not directly in the isc.statistics package.  We
 could either introduce a helper module for xfrout and define its
 counter there or implement directly in xfrout.  Maybe the former is
 better in terms of modularity.

 > - We should complete implementation of an abstract counter class like
 #2300 in advance.

 I think so.  At least in the current form I cannot be sure whether the
 idea of the abstract class is good or not.

 In addition, in my opinion I'd avoid implementing counter objects at
 the module scope.

 BTW: I've given an initial view to the ticket as it's been mostly
 forgotten for quite a long time, but I'm afraid I have too many things
 on my table now.  When you complete it, I think it's better to ask
 someone else to give it a full review.

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


More information about the bind10-tickets mailing list