BIND 10 #1112: RR type implementation: HINFO

[BIND 10 Development]

#1112: RR type implementation: HINFO
-------------------------------------+-------------------------------------
                   Reporter:  shane  |                 Owner:  vorner
                       Type:         |                Status:  reviewing
  enhancement                        |             Milestone:
                   Priority:  minor  |  Sprint-20110927
                  Component:         |            Resolution:
  libdns++                           |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  3
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by ocean):

 * owner:  ocean => vorner


Comment:

 Replying to [comment:10 vorner]:
 > Hello
 >
 > Replying to [comment:8 ocean]:
 > > Replying to [comment:7 vorner]:
 > > > Regarding the move of common methods to utils (or somewhere so they
 can be reused), I think it would not only be nice, but actually required.
 I think having two copies of the same code could qualify as a bug. So,
 will you move them, please?
 > >
 > > Done, move {{{getNextCharacterString()}}} to {{{character_string.cc/h
 files}}}
 >
 > As they are separate functions, should they have their own tests now?
 Done. Add separated unit tests.
 >
 > > > Another thing I noticed ‒ do the string data allow containing the
 quotes? How are they escaped in the text format, if they are allowed?
 (they don't seem to be at all in the code)
 > >
 > > Done. Add the double quotes escaping support.
 >
 > Hmm, as you referenced the 1035 RFC, I had a look there and it seems
 that character strings have quite complicated escaping support (so you can
 actually write {{{"\h\\\"ello"}}} and it would mean „{{{h\"ello}}}“).
 Strinctly speaking, the functions should be able to decode that. However,
 I'm thinking ‒ we surely must have a function to parse these somewhere.
 Or, if not, it should be added (but in that case, maybe as a separate
 ticket, I don't know…). What do other RRTypes parsing string data use?
 I checked the {{{txt_16.cc}}} it does not support escaped characters now,
 it will just throw an exception if an escape character '\' is encountered.
 Anyway, I added the escaped characters support, please help to review it.
 >
 > > > And, that might be more general problem, but both toWire methods
 have the exact same code. Should we consider reusing the code in some way?
 (template parameter and hidden implementation? Or something?)
 > >
 > > Done. Move them to a {{{toWireHelper()}}} function. But I'm not clear
 what '''hidden implementation''' means, can you give more detailed
 explanation? thanks.
 >
 > Well, it's not some kind of technical term, I just meant as little as
 possible should be visible of the function from outside. In fact, the body
 of the function might be put into the .cc file, as it is used only from
 there (template functions must have the body available when they are
 instantiated/called, but it is called only from the .cc). Unfortunately,
 the header can't be hidden there as well it seems.
 >
 > > BTW. I also update the code of {{{naptr_35.cc/h}}} which is
 implemented in #1130, can this be reviewed in this ticket or I need to
 reopen #1130?
 >
 > It's OK to be reviewed here.

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