BIND 10 #1427: Socket cache

BIND 10 Development do-not-reply at isc.org
Fri Dec 2 12:07:55 UTC 2011


#1427: Socket cache
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jelte
  vorner                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20111206
                  Component:  Boss   |            Resolution:
  of BIND                            |             Sensitive:  0
                   Keywords:         |           Sub-Project:  Core
            Defect Severity:  N/A    |  Estimated Difficulty:  0
Feature Depending on Ticket:         |           Total Hours:  0
  Socket creator                     |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jelte


Comment:

 Hello

 Replying to [comment:4 jelte]:
 > one style issue; the nameCompatible() method name isn't following the
 > style guideline (should be share_compatible())

 Ah, of course. I'm still mixing python and C++ styles.

 > In general the code looks ok, the spaghetti of sets and dicts is a bit
 > worrying though. Not so much as that it is too complicated as it is,
 > but what worries me is when other people might need to change
 > something in the future. But apart from adding some graph somewhere
 > which will no doubt go stale I don't really have any suggestion for it,
 > so you may just ignore this worry :p

 Well, there would be other option, which is slower and probably more work
 to code, but it would be simpler with regards to the structure. The
 sockets could be in a list and a linear search for whatever is needed
 would be performed each time. The advantage would be there would be only
 one list, not multiple indexing hashes and stuff. But I personally prefer
 this approach, as it is cleaner design-wise and is already written. Or
 should I change it?

 > there are a few instances where emptiness is checked with 'foo ==
 > set()'. I'd personally prefer len(foo) == 0

 Hmm, changed. But not in the tests, as assertEqual(set(), var) will
 produce nicer are more useful output when it goes wrong.

 > similarly, sets have a copy() method, which i would personally
 > choose over set(foo)

 ACK.

 > anyhow, these are minor, and apart from the name thing in the
 > beginning, I think this code can be merged.

 I'll merge it once the other two are reviewed. No need to have it in
 master yet.

 With regards

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


More information about the bind10-tickets mailing list