BIND 10 #1179: python interface for data source

[BIND 10 Development]

#1179: python interface for data source
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jelte
  jinmei                             |                Status:  assigned
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20110927
                  Component:  data   |            Resolution:
  source                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  4
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jelte):

 Replying to [comment:4 jinmei]:
 > I couple of points that may be helpful:
 >
 > - I suspect a straightforward implementation of this python wrapper
 >   would need to get access to symbols (and perhaps class/structure
 >   definitions also) defined in pydnspp.so, which would be very tricky
 >   (or may be mostly impossible if we want to be portable).  I
 >   encountered this issue for the DNS ACL wrapper, and my resolution at
 >   that time was to use an intermediate frontend written in Python that
 >   converts pydnspp objects to other Python native objects via
 >   serialization so that the C++ wrapper itself wouldn't have to use
 >   pydnspp definitions directly.  You may need to do the same thing (or
 >   may find a better solution).

 Hmm. Having a 'real' .py in front of the module is a pretty common way to
 define modules i believe. It does 'cost' yet another layer, but it allows
 one to put pydocs in, and handle some python-specific code in actual
 python. This has been discussed somewhere in the beginning but right now I
 can't remember why we did this.

 However, just translating from pydnspp isn't enough; ideally we would have
 shared conversion functions between PyObjects of a certain type and our
 c++ classes, e.g. DNSNameToPyObject(Name) and PyObjectToDNSName(PyObject).
 Such functions would be useful in a number of places, but mainly when we
 wrap a function that returns a type from another wrapper class (like
 getNextRRset() in ZoneIterator).

 I am not sure that serialization may not work in all cases (then again,
 maybe it does).

 FYI, so far I have implemented the basic DataSourceClient (initialized
 with a hardcoded sqlite3 backend, pending the factory functions), and
 ZoneIterator, so we can now iterate over zone content (works with one of
 the example dbs). In order to take another look at the issues and
 potential solutions I have added some conversion code inline. We do indeed
 need at least to *_type structure (for ParseTuple), though that *could* be
 circumvented. But s_Type-like structres would be needed. Perhaps we can
 make add converter functions to the specific class headers? (like
 name_python.h) Or would there be a problem having the linker dependency on
 pydnspp then?

 Oh I also found that rrset_python didn't match the 'template', and had no
 header files. I have modified it to be more like the others. A bigger
 problem I found was that if something returns const RRset (or probably any
 type) it's quite hard to make an python object out of it (for now i create
 a new one, and copy in the data). Perhaps we'll also need a clone() method
 in some of our c++ types to make a non-const copy of a const object.

 The code is not pushed yet, but if you want to take a look at it before we
 discuss cross-wrapper functionality, I could push it so an experimental
 branch (I want to rebase this one as some other tickets get resolved).

 > - I suggest considering the use of
 src/lib/util/python/pycppwrapper_util.h
 >   to avoid various pitfalls of the Python C API (see the doc in the
 >   file for more details).  The mkpywrapper script with the template
 >   C++ files may also be useful.

 I used it for one class so far, had to strip out almost all of the code it
 provides, but it does give a nice framework to start typing in :)

 > - To generate pydoc in the C++ wrapper code, you may find the conversion
 script useful.  See my message on bind10-dev:
 https://lists.isc.org/pipermail/bind10-dev/2011-August/002603.html
 >

 cool, thnx :)

-- 
Ticket URL: <http://bind10.isc.org/ticket/1179#comment:5>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development