BIND 10 #446: configuration knob for in memory data source

[BIND 10 Development]

#446: configuration knob for in memory data source
---------------------------+------------------------------------------------
      Reporter:  jinmei    |        Owner:  vorner               
          Type:  task      |       Status:  reviewing            
      Priority:  major     |    Milestone:  y2 12 month milestone
     Component:  b10-auth  |   Resolution:                       
      Keywords:            |    Sensitive:  0                    
Estimatedhours:  0.0       |        Hours:  0                    
      Billable:  1         |   Totalhours:  0                    
      Internal:  0         |  
---------------------------+------------------------------------------------

Comment(by jinmei):

 Replying to [comment:5 vorner]:

 > Anyway, as it is used outside the module only inside tests and tests are
 kind of part of the module itself, I think 2 is the best of them. 1 would
 be fine too, as the only problem it causes is confusion.
 >
 Okay, then I'll go with option 2.

 As for the new/delete incompatibility:

 > Do we expect to have incompatible versions of new and delete? I know C++
 can overload these, but do we want to do that?
 >
 "We" probably don't, "they" may.  For public interfaces I generally try to
 be conservative with fewer assumptions about how it can be used.  Also,
 again technically, even between our own modules the incompatibility could
 happen if they are built separately with different (versions of) compilers
 and/or different standard libraries.

 > The destructor and exception, OK, I remembered wrong. But I think we
 have (maybe unwritten) requirement that destructors don't throw, so
 specifying that they could is somehow wrong. It sounds like we expect them
 to do so.
 >
 Point taken.  I actually had an undocumented scenario in my mind where
 this configuration interface is used by external developers to extend the
 server behavior without modifying the main source code (with some
 dynamically linkable hooks which are currently not available).  Like the
 case with new/delete, I tend to act conservatively when I expect something
 to be used by a third party.

 Anyway, if our choice is option 2, we'll simply remove these controversial
 descriptions, so the problem will disappear:-)

 > With the exception, I think throwing an exception that should not be
 caught (or, when did, it should be rethrown) is the option. Like if the
 parser can't avoid it, instead of pretending everything is OK, it would
 abort the program, but with anything on the path out of main being able to
 know.
 >
 I'm not sure if I understand this suggestion, but on reading this comment
 my proposal is:
  - still suggest (but not "require") the derived classes of
 AuthConfigParser be designed so that commit() is exception free (and
 build() does any tricky work) in documentation
  - catch all exceptions from AuthConfigParser::commit() in
 configureAuthServer() and covert them to a FatalError exception and
 rethrow it

 Does that work for you?

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