Commit 856ff83a authored by JINMEI Tatuya's avatar JINMEI Tatuya
Browse files

[1199] corrected the description of the ZoneFinder class.

directly committed and pushed for master.
parent 7cc9b08f
......@@ -23,40 +23,31 @@
namespace isc {
namespace datasrc {
/// \brief The base class for a single authoritative zone
/// \brief The base class to search a zone for RRsets
/// The \c Zone class is an abstract base class for representing
/// a DNS zone as part of data source.
/// The \c ZoneFinder class is an abstract base class for representing
/// an object that performs DNS lookups in a specific zone accessible via
/// a data source. In general, different types of data sources (in-memory,
/// database-based, etc) define their own derived classes of \c ZoneFinder,
/// implementing ways to retrieve the required data through the common
/// interfaces declared in the base class. Each concrete \c ZoneFinder
/// object is therefore (conceptually) associated with a specific zone
/// of one specific data source instance.
/// At the moment this is provided mainly for making the \c ZoneTable class
/// and the authoritative query logic testable, and only provides a minimal
/// set of features.
/// This is why this class is defined in the same header file, but it may
/// have to move to a separate header file when we understand what is
/// necessary for this class for actual operation.
/// The origin name and the RR class of the associated zone are available
/// via the \c getOrigin() and \c getClass() methods, respectively.
/// The idea is to provide a specific derived zone class for each data
/// source, beginning with in memory one. At that point the derived classes
/// will have more specific features. For example, they will maintain
/// information about the location of a zone file, whether it's loaded in
/// memory, etc.
/// The most important method of this class is \c find(), which performs
/// the lookup for a given domain and type. See the description of the
/// method for details.
/// It's not yet clear how the derived zone classes work with various other
/// data sources when we integrate these components, but one possibility is
/// something like this:
/// - If the underlying database such as some variant of SQL doesn't have an
/// explicit representation of zones (as part of public interface), we can
/// probably use a "default" zone class that simply encapsulates the
/// corresponding data source and calls a common "find" like method.
/// - Some data source may want to specialize it by inheritance as an
/// optimization. For example, in the current schema design of the sqlite3
/// data source, its (derived) zone class would contain the information of
/// the "zone ID".
/// <b>Note:</b> Unlike some other abstract base classes we don't name the
/// class beginning with "Abstract". This is because we want to have
/// commonly used definitions such as \c Result and \c ZoneFinderPtr, and we
/// want to make them look more intuitive.
/// \note It's not clear whether we should request that a zone finder form a
/// "transaction", that is, whether to ensure the finder is not susceptible
/// to changes made by someone else than the creator of the finder. If we
/// don't request that, for example, two different lookup results for the
/// same name and type can be different if other threads or programs make
/// updates to the zone between the lookups. We should revisit this point
/// as we gain more experiences.
class ZoneFinder {
/// Result codes of the \c find() method.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment