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