[bind10-dev] initial thoughts about zone file loader

[JINMEI Tatuya / 神明達哉]

At Wed, 23 May 2012 10:31:42 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > > And, while thinking about this, I've also come up with a proposal on a
> > > related topic: how we can make RDATA implementation more easily.  I've
> > > created another wiki page about it:
> > > http://bind10.isc.org/wiki/RdataAPIFramework
> 
> Looking at it, I'd have some questions and/or suggestions:
> 
> Do we have time to do the switch? Or, do you think that by
> implementing this, we could save some time when implementing the
> RRTypes we don't yet have and leave the current Rdata
> implementations as they are?

Fair questions, and some are open to myself.  But what I generally
thought was:

- at least implementing (and testing) the rest of known RR types will
  be much easier and faster.  of course, we'll still need to take into
  account the implementation overhead of the framework itself, and
  consider which one in total is more efficient in terms of
  development time.  for that, I'm not 100% sure.  I didn't think the
  implementation cost of the framework was that high, but we could
  easily underestimate such things, especially when we love the idea.
- I also believe that helps others introduce their
  experimental or not-just-yet-implemented RR types much easier.  Such
  extendability for external developers is (in my understanding) an
  important goal of BIND 10.  Again, however, I understand we first
  need to focus on completing our own development sooner.  So if it
  causes a non negligible delay, the advantage may not be justifiable.
- Existing RR type implementations don't necessarily have to be
  adjusted (although I believe it's easier fix remaining bugs in them
  with the new framework).  But in any event the existing ones will at
  least have to be updated so they'll use the generic lexer in order
  for them to be usable in a generic zone loader, so they are not
  completely modification-free, whether or not we adopt this proposal.

> So, will this allow that several different RRTypes will be represented by a
> single concrete class?

I still thought different types would be implemented as different C++
types (classes) for better type safety.

> I was thinking, if they have no member variables, all their methods could be
> static and we could use them in a template-like manner instead of using virtual
> functions. These could be inlined and we could gain some more performance and
> possibly more type safety. Then we could create new Rdata classes by just
> defining the list as template parameter somehow. Would it make sense?
> 
> Like (using the type list approach):
> 
>   class SRV : public RDataImplementation<P<IntField, P<IntField, P<Int16Field, P<NameField, EndList> > > > > { };

I've not fully understood this in detail, but if the use of template
reduces implementation overhead further, I think that's worth
considering.  Note, however, the RDATA classes should still be able to
be used in a polymorphic way from a higher level classes such as
RRset.  I'm not sure it can be cleanly realized with the definition
above.  Also, for conversion from text I suspect the performance
benefit due to inlining or avoiding virtual method calls is relatively
minor.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.