BIND 10 #2500: support generic version of rdata::createRdata(text) in SOA

[BIND 10 Development]

#2500: support generic version of rdata::createRdata(text) in SOA
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  jinmei
            Priority:  medium        |                       Status:
           Component:  libdns++      |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130122
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  3             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |  loadzone-ng
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:10 vorner]:

 > I think I've seen some code like this somewhere. Can it be unified?
 > {{{#!c++
 > createName(MasterLexer& lexer, const Name* origin) {
 >     const MasterToken::StringRegion& str_region =
 >         lexer.getNextToken(MasterToken::STRING).getStringRegion();
 >     return (Name(str_region.beg, str_region.len, origin));
 > }
 > }}}

 I believe this is the first RDATA that starts using lexer and has
 a domain name field (so there should be no other use cases in RDATA
 implementations).  But I extracted it to a separate function defined
 in a separate helper header file so some other RDATA tasks that follow
 can use it.

 The only other point I can think of is in master loader:

 {{{#!cpp
         const MasterToken&
             name_tok(lexer_.getNextToken(MasterToken::QSTRING,
 is_optional));

         if (name_tok.getType() == MasterToken::QSTRING ||
             name_tok.getType() == MasterToken::STRING) {

             const MasterToken::StringRegion&
                 name_string(name_tok.getStringRegion());
             active_origin_ = Name(name_string.beg, name_string.len,
                                   &active_origin_);
 }}}

 but the usage is slightly different, and the code is not that big
 anyway, so I didn't touch it.

 > Also, AFAIK the loader accepts `QSTRING` for names. I think we said that
 it's not completely correct, but we mimic bind9 behaviour there. Should we
 be consistent here?

 Hmm, good point.  I'd personally (slightly) prefer to reject QSTRING,
 and I sent a message to the dev list for discussion.  I suspect this
 is quite minor and no one actually cares though, so unless there's
 strong opinion either from the list or from you, I'll merge the branch
 as it is.  Right now, I clarified it in comments and added test cases.

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