[bind10-dev] Datasource API

Jelte Jansen jelte at isc.org
Tue Jan 5 15:59:05 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Here's a general throw at something to get us started; example header is
based on the current name API header files in the parkinglot branch
(since that is where i plan on prototyping this, and jinmei can tell us
how his current work will let us do some of this better and the rest of
us can remark where there is room for improvement that hasn't been noted
yet)

For starters, let me be clear on what is my view of what we call the
data source; in essence i think of it as an interface, that if you
implement it, can be used by our future authoritative server module to
use as the backend. This means that it needs to be able to provide DNS
data in a form that our module understands, regardless of how it stores
that data itself. Also having some fixed way to import and update zone
data would be nice (though imho, this should not be mandatory for every
backend, as those may have methods for updating themselves).

So at the minimum the class will need virtual functions for getting
data, adding data, and removing data (sound familiar? heh). There will
probably be a few different kinds of data in that basic set of methods.
These lowlevel methods need to be defined by the specific data source
implementation classes.

On top of that, the plan is to make more advanced methods that use those
lowlevel ones to actually get from a query to an answer, and to do the
more magical stuff that happens when updates occur. The basic idea is
that if you write a new back-end, you start out by implementing the
low-level ones, which already gives you a working data source, albeit
one that may not be very efficient. You then have the option to also
redefine the high-level functions to make use of shortcuts your data
model allows you to.

So here's a first stab at a base class that would provide at least some
of what we need; there's probably a lot to add but let's hope this gets
things started.

Based on this, i think i could get a DataSourceParkingLot done pretty
quickly, but if anyone thinks this is completely not the way to go,
please let me know before tomorrow ;)

Jelte

ps. we'll probably need a more advanced getRRset(), and i have not
thought about how we could do history for ixfr at all yet

#ifndef __DATA_SOURCE_H
#define __DATA_SOURCE_H

#include "name.h"
#include "rrset.h"

namespace isc {
namespace dns {

// Base class for a DNS Data Source
class DataSource {
public:
    enum result { success, not_implemented, error, zone_not_found,
                  name_not_found };

    DataSource() {};
    virtual ~DataSource() {};

    //
    // 'high-level' methods, these may or may not be overwritten;
    // depending on the data source the default implementation
    // may not be most efficient, but should at least provide
    // the needed functionality
    //

    // fill in separate lists or simple fill in an answer Message object?
    result getData(const RRsetPtr query, Message& answer);

    // how to provide highlevel update data?
    //result handleUpdate()


    //
    // mandatory 'low-level' methods, an implementation must overwrite these
    //
    virtual result getRRset(RRsetPtr target, const Name name,
                            const RRClass clas, const RRType type) = 0;

    //
    // optional 'low-level' methods, an implementation may overwrite these,
    // by default they return not_implemented
    //
    virtual void init() {};
    virtual void close() {};
    virtual result addRR(Name name, int clas, int type,
                         int ttl, Rdata::RdataPtr data)
                        { return not_implemented; };
    //how to specify what exact rr to delete? just pass an rrsetptr?
    //virtual result delRR() { return not_implemented; };
    // on name/class/type again? or use an already constructed object?
    virtual result getRRSigs(RRsetPtr target, const RRsetPtr rrset)
                            { return not_implemented; };
    virtual result getNSECs(RRsetPtr target, const RRsetPtr rrset)
                            { return not_implemented; };

    // check if the zone exists, and if so, return something that could
    // be used as a pointer for the rest of these functions?
    // do we need this? do we want this?
    //virtual int getZone(void* zone, isc::dns::Name name);

};

}
}

#endif
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktDYckACgkQ4nZCKsdOncUOXQCdExd+yY5/N1/O/kPh1oERM+Lc
Il8AoNKmTpdMXJvIMLUwzMN7MTKm3mkh
=04pW
-----END PGP SIGNATURE-----



More information about the bind10-dev mailing list