[bind10-dev] python bindings

[Francis Dupont]

Oops, locked in my mailbox... I apologize for the delay.

> > I looked at python bindings for BIND 10 (the Name class from parkinglot),
> > I have some comments:
> >  - there is a dependency on *recent* versions of automake:
> >   old versions of automake (i.e., the version you should get on most
> >   distribs per default) fail to recognize python 3
> 
> I'm not sure about the point...are you suggesting something specific?

=> up to automake 1.10 included the aclocal-1.10/python.m4 finished by:
...
minver = map(int, string.split('$2', '.')) + [[0, 0, 0]]
                  ^^^^^^^^^^^^
the string.split always fails with python3 so configure fails saying
it can't find a python3 interpreter even it is clearly wrong.
in automake 1.11 (and newer, today 1.11.x) you have the fixed:
...
minver = list(map(int, '$2'.split('.'))) + [[0, 0, 0]]

which works with all not antic versions of python.

So I suggest to add a warning in INSTALL about this, i.e.,
if ./configure fails to find python3 where there is one, check automake
version and switch to >= automake 1.11

> >  - 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.

> >  - for DNSSEC we need a canonize/specialized toWire/..., at least something
> !
> 
> Could you be more specific?  Are you talking about name.toWire or
> rr(set).toWire?  BTW, if you mean name.toWire with downcasing
> upper-case characters, we could do this with the simple toWire() +
> specific "downcase" method (the latter is not yet implemented).

=> canonize == downcase, specialized toWire == toWire o downcase
There are many options but we need one of them.

> >  - 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.

> 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 ...)

> >  - the bug exists for parkinglot but I am afraid it is shared:
> >   Name::Name("") raises a runtime error.
> 
> It's by design (BIND9's dns_name_fromtext() rejects an empty string,
> too, and the name class follows that convention).  We should
> explicitly note that in the documentation though.

=> I agree it is a wrong input but I have a real concern about the
runtime error: it must be a DNS exception!

Thanks

Francis Dupont <fdupont at isc.org>