BIND 10 #1604: reorganize RRset class hierarchy to allow further optimization
BIND 10 Development
do-not-reply at isc.org
Tue Jan 31 16:20:48 UTC 2012
#1604: reorganize RRset class hierarchy to allow further optimization
-------------------------------------+-------------------------------------
Reporter: | Owner: stephen
jinmei | Status: reviewing
Type: task | Milestone:
Priority: major | Sprint-20120207
Component: | Resolution:
libdns++ | Sensitive: 0
Keywords: | Sub-Project: DNS
Defect Severity: N/A | Estimated Difficulty: 5
Feature Depending on Ticket: auth | Total Hours: 0
performance |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Changes (by vorner):
* owner: vorner => stephen
Comment:
Hello
First, I'm not sure it is the best thing to do to throw NotImplemented on
getRRsig. While adding it to something that doesn't support RRsigs gives
little choice, the natural answer here is returning NULL, because, by
definition, if they are not implemented, they aren't there. Provided we'll
get RRsigs more often than set them, this will simplify the handling,
because we need to take care of the case where the RRsig is not there
anyway and it's hard to imagine anyone would like to distinguish between
„not there“ and „not there because there's no there to put it“.
With the addRRsig methods, would it be better to give the parameter (like
`rdata::ConstRdataPtr`) by reference? I know this wasn't introduced here,
but provided we touch the interface now with a backwards incompatible
change, it might be worth to piggy-back this little change with it.
Not about this exact branch, I guess, but looking at the descriptions, is
there no way to just „attach“ the RRsig RRset, instead of creating a new
one inside and copying everything?
I don't know if there's much we can do about it, but the part with
Associated RRsig methods in BasicRRset looks too much like a copy-paste,
including the documentation. I fear that if we ever need to change
anything there, we'll forget to change all the copies and we'll get
inconsistency.
Thank you
--
Ticket URL: <https://bind10.isc.org/ticket/1604#comment:7>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list