Opened 7 years ago

Closed 6 years ago

#3002 closed task (wontfix)

extend datasrc::(Configurable)ClientList::find to return data source name

Reported by: jinmei Owned by:
Priority: medium Milestone: Remaining BIND10 tickets
Component: data source Version: bind10-old
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket: shared memory data source
Estimated Difficulty: 3 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

This will be needed for the shared memory support, so it's a subtask
of #2830.

For xfrin and ddns to tell memmgr to reload the updated zone,
they need to specify the corresponding data source name.
We currently don't have an interface to make it possible and need to
extend the API.

My suggestion is to revise ConfigurableClientList::find() so it can
optionally return the data source name:

    virtual FindResult find(const dns::Name& zone,
                            bool want_exact_match = false,
                            bool want_finder = true,
                            bool want_datasrc_name = false) const;

And also revise the FindResult structure in the obvious way.
If want_datasrc_name is true, the find() method will copy
the data source name to FindResult; if it's false it will probably
be an empty string.

We also need a Python wrapper (actually we'll only need the Python
wrapper for the feature).

And, as usual, there'll be a confusion of whether this should be a
virtual method and be implemented in the base ClientList class.
Technically, the answer is yes because C++ applications are expected
to use the ClientList interface only.

Subtickets

Change History (6)

comment:1 follow-up: Changed 7 years ago by vorner

Isn't the name stored as a string directly in the client list somewhere? So if we returned just const reference to it, it should be safe to use that as long as we don't reconfigure the client list and it would be cheap operation, so we wouldn't need the boolean flag and could return it every time. It could be simpler interface (and backwards compatible).

comment:2 in reply to: ↑ 1 Changed 7 years ago by jinmei

Replying to vorner:

Isn't the name stored as a string directly in the client list somewhere? So if we returned just const reference to it, it should be safe to use that as long as we don't reconfigure the client list and it would be cheap operation, so we wouldn't need the boolean flag and could return it every time. It could be simpler interface (and backwards compatible).

The data source name is stored in DataSourceInfo
(ref. http://bind10.isc.org/attachment/wiki/DataSourceClasses/overview.png).

I'm not sure what exactly you meant above, but from that I guess one
other approach is to include DataSourceInfo in ClientList::FindResult
as a private member, and provide accessor(s) to some selected members
such as data_src_client_ or name_ (although I'd like to hide the
existence of DataSourceInfo as much as possible even as a private
member of some other class, and in that sense this approach is not
very clean). With this approach we'll probably need to maintain
DataSourceInfo as a shared pointer in the vector, and this will
eliminate the need for the LifeKeeper trick.

Yet another approach is to simply include the data source name
unconditionally. It's a bit suboptimal in terms of efficiency
especially because the data source name won't be needed in many cases
(and especially not in performance sensitive cases). But copying
std::string should be reasonably cheap for its common implementations
using a reference counter, and since ClientList::find() is called
only once in the entire query processing, this may be a reasonable
compromise.

comment:3 Changed 7 years ago by muks

  • Estimated Difficulty changed from 0 to 3

comment:4 Changed 7 years ago by shane

  • Milestone New Tasks deleted

comment:5 Changed 6 years ago by tomek

  • Milestone set to Remaining BIND10 tickets

comment:6 Changed 6 years ago by tomek

  • Resolution set to wontfix
  • Status changed from new to closed
  • Version set to old-bind10

This issue is related to bind10 code that is no longer part of Kea.

If you are interested in BIND10/Bundy framework or its DNS components,
please check http://bundy-dns.de.

Closing ticket.

Note: See TracTickets for help on using tickets.