BIND 10 #2208: Revise InMemoryClient and ConfigurableClientList::configure() using ZoneTableSegment
BIND 10 Development
do-not-reply at isc.org
Mon Oct 22 14:17:56 UTC 2012
#2208: Revise InMemoryClient and ConfigurableClientList::configure() using
ZoneTableSegment
-------------------------------------+-------------------------------------
Reporter: | Owner: muks
jinmei | Status: reviewing
Type: task | Milestone:
Priority: | Sprint-20121023
medium | Resolution:
Component: data | Sensitive: 0
source | Sub-Project: DNS
Keywords: | Estimated Difficulty: 5
Defect Severity: N/A | Total Hours: 0
Feature Depending on Ticket: |
background zone loading |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Changes (by jelte):
* owner: jelte => muks
Comment:
Replying to [comment:9 muks]:
>
> > Isn't that hardcoded RRClass::IN() going to present a problem (given
that the 'static' datasource also uses in-memory)?
>
> I am assuming you mean the hardcoding inside `ZoneTableSegment`'s
factory method. We have to decide upon config syntax for it. The factory
would construct the appropriate `ZoneTableSegment` based on the passed
memory model, RRClass, etc. in config.
>
> Also, currently the static datasrc doesn't use the new in-memory code.
But we have to address this issue when we decide upon config.
>
Right, but I'm hesitant to add more to do before we can switch that one :)
But isn't the class already in the configuration? (though from the looks
of it at a 'higher' level than what is currently passed to the factory). I
don't think we're gonna put class in there twice, and I don't think there
are any plans to move it away.
The clientlist already knows it afaict, so perhaps it should just be
passed to the factory function there.
For the rest it looks fine
--
Ticket URL: <http://bind10.isc.org/ticket/2208#comment:10>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list