[bind10-dev] python bindings

[JINMEI Tatuya / 神明達哉]

At Wed, 16 Dec 2009 16:04:33 +0000,
Francis Dupont <fdupont at isc.org> wrote:
> 
> Oops, locked in my mailbox... I apologize for the delay.

No problem, I wouldn't respond so quickly anyway:-)

answering some selected points...

> > >  - a hash method is really needed (not only for python but I can't see
> > >   a DNS tool without a hashtable with names as keys)
> > 
> > Adding a name hash is easy.  The question is which hash algorithm we
> > should use.  In BIND9, we needed to make it unpredictable to avoid a
> > certain kind of DoS attacks and ended up implementing a universal hash
> > in libisc.  My understanding is that we generally want to avoid this
> > type of wheel reinvention in BIND10, but I don't know which algorithm
> > we should use this time and whether there's a reasonable existing
> > wheel (boost::hash?).
> 
> => IMHO the unpredictable point can be critical for the same reasons.
> For the algo itself I like jhash (even it is used in Linux it has a
> decent license), it is easy to make it unpredictable by adding a
> pseudo random seed in it. Look at AFTR for examples.

I'd be more interested in whether to implement the hash algorithm,
developing an in-house library (like BIND9) or using an existing one,
rather than which algorithm.  (in this sense my original question
wasn't well described).  I guess in AFTR you chose jhash as the
algorithm and implemented (ported?) it as an in-house library.  I
thought we'd avoid the in-house approach where possible.

> > >  - for using the C++ class in dnspython, set/get methods to labels
> > >   (a vector of labels?) is required. (Note dnspython is python 2.6,
> > >   not python 3).
> > 
> > I'm not sure about the implication...are you thinking about making our
> > python bindings compatible with dnsypython?
> 
> => with a python bindings compatible with dnspython we can replace
> the Name class from dnspython with ours, and get a lot of python code
> to exercise... This is the reason I am interested by python bindings BTW.

Okay, I see the motivation, but unless we make the entire DNS API (not
just the name class) fully compatible with dnspython, which I suspect
won't be the case, some level of porting effort will be inevitable
anyway.  And I guess dnspython compatibility can be provided within
our python bindings without enhancing the C++ API.  For example, to
construct a name from a tuple of labels (ala dnspython), we could
first convert the tuple to a name string:
  reduce((lambda x, y: x + '.' + y), labels)
and construct a BIND10 name class object from that.

I'd personally like to keep the C++ API minimal at least at the
beginning, and if the main reason for enhancing it is to provide
compatibility with dnspython, I'd rather handle it outside of the C++
API.

> > Please refer to branches/jinmei-dnsmessageapi.  It's what I'm going to
> > get reviewed (and mostly ready for that).
> 
> => can you make the default constructor (Name::Name()) available?
> It is possible to call a constructor from python __init__ but only
> one of them and here you have two (from text or wire).
> (note I'll try to find a way to use factory functions but ...)

Hmm...I actually thought about whether we need to make the default
constructor public.  The reason why I made it private in the current
branch is because the default constructor makes an empty name (i.e., a
name object with no labels).  If we allow applications to construct a
name that way we need to handle such cases in other methods, making
the code complicated.  So, I chose to keep it private at the moment
until there's a strong reason to make it public.

I'm not sure if this is strong enough to have a public default
constructor.  But if we encounter another case, possibly in other part
of the C++ version of the API, where we'd need it, I'll make that
change.

---
JINMEI, Tatuya