[bind10-dev] initial thoughts about zone file loader

[Michal 'vorner' Vaner]

Hello

On Wed, May 23, 2012 at 10:26:07AM -0700, JINMEI Tatuya / 神明達哉 wrote:
> - 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.

That's a fair point, thought it's probably out of scope of this year.

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

Hmm, right. So it could help a lot if done well.

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

Well, the RDataImplementation could be inherited from the base class, so it
could be handled polymorphically, but we would lose the (small) advantage of not
having virtual methods.

Anyway, the templates would probably be slightly harder to read (the templates
itself), but I think it could be easier to use under some circumstances.

The thing with the type list is something like functional-programming-like
linked list and you can use it by specializing the templates, so we could have
several correctly-sized typed variables instead of correctly sized byte buffers.
So we could have something like DataContainer class:

  template<> class DataContainer<EndList> {};
  template<class FirstType, class Rest> class DataContainer<P<FirstType, Rest> >
  {
    DataContainer<Rest> rest;
    FirstType data;
    template<> FirstType getData(size_t index) const {
      if (index == 0) {
        return (data);
      } else {
        return (rest.getData<FirstType>(index - 1));
      }
    }
    template<Type> Type getData(size_t index) const {
      if (index == 0) {
        isc_throw(Unexpected, …);
      } else {
        return (rest.getData<Type>(index - 1));
      }
    }
  };

Then the RDataImplementation would contain this kind of recursively-build class
to hold the data. It could then call dataContainer.get<int>(3) or something like
this.

If we used a template parameter for the index too, we could probably detect the
request for a wrong type of field at compile time.

For this to work, we would probably need to pass the real types (eg. uint_16t)
as the template parameters and do the field parsers/renderers you propose as
template specializations.

With regards

-- 
I have a theory that it's impossible to prove anything, but I can't prove it.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20120524/cdf3e72b/attachment.bin>