BIND 10 #1788: update auth spec to specify in-memory "filetype" with sqlite3 backend

[BIND 10 Development]

#1788: update auth spec to specify in-memory "filetype" with sqlite3 backend
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120417
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  3
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:  xfr    |
  for in-memory                      |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:6 vorner]:

 Thanks for the review.

 >  * While this is out of the scope of this ticket, I believe we could use
 an „enum“ config type. It would be a nicely dressed string, but with only
 a list of allowed values checked even in bindctl and with tam completion.
 This is another place it would be useful. Would you mind if I create one?

 That seems to make sense.

 >  * Should the tests also check the `errors_` list is empty?

 I don't think so, and actually I realized the test could have been
 simplified.  Did it.

 >  * The `699f21c00c5136c0128cfbb842c1d3218de11cfe` commit might have had
 a better message (as we talked last week on the call). It's probably not
 worth fixing now, but some future ones might want to hint tests for what
 these are in the body of the message.

 I knew that one was blunt...I don't know if it addresses the comment,
 but I've revised the commit log. (see
 36ec15a2721f408c1868001f8dfa4c358f2f0ec3).  Note: I used git rebase
 and it resulted in conflicts with the central repo, and required
 re-merge.

 >  * I don't think „optional“ goes very well together with „default“.
 Optional means the option may or may not be present at all (therefore it
 would have _no_ value). The default is that the option is there all the
 time, but it has this value if not set. The combination of both leads to
 the fact the default must be hardcoded in the code, which is bad (the
 default is at two different places). Do you think it would be possible to
 make it non-optional and have a default value?

 Hmm, you're right.  I'm always confused about the meaning of
 "optional" for the config system.  I'd argue it's quite misleading and
 should be somehow clarified, but in any event the use of optional with
 default was not a good choice.  I could change it to non-optional, but
 chose a different solution - see 24e67649252ab7dbb1b1f7c943a995998c7f2052.

 In future, I'd like to make it sure that it's ensured that the config
 parser is always given syntactically validated config data (right now
 it can be arbitrary element data, so it also has to do some syntax
 level checks, which is a kind of duplicate).  At that point we can
 revise the overall parser implementation and test cases, and make
 things like this to non-optional in a safer manner.

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