BIND 10 #243: Put spec files together in source tree

[BIND 10 Development]

#243: Put spec files together in source tree
--------------------------+-------------------------------------------------
 Reporter:  jelte         |       Owner:     
     Type:  enhancement   |      Status:  new
 Priority:  major         |   Milestone:     
Component:  Unclassified  |    Keywords:     
Sensitive:  0             |  
--------------------------+-------------------------------------------------
 Originally, the idea of the .spec file was to have one single thing that a
 new module could simply send to the configuration manager or other
 interested software pieces, that described what the module expects and can
 handle in terms of commands an configuration.

 The idea was that on startup, it reads in this file, sends it to
 ConfigurationManager, and all would be fine. However, we're running into a
 few snags.

 One is that other modules might need a configuration value of another
 module (e.g. xfrin needs the location of the database_file from auth right
 now, this example may change in the future but there will probably be
 others). For that we have the add_remote_config() and
 get_remote_config_value() functions in CCSession.

 However, since the only real fixed pointer to what may be in the config is
 this spec file, the module wanting data from another must have access to
 it. Which isn't necessarily a problem, but the location of the file might
 be when we run from source tree (in which case all spec files are in
 different locations, and we now end up with hardcoded src/bin/auth paths
 etc.).

 Another thing that arised is that we might need to change configuration of
 modules that aren't running, and while we can do that now, there is no
 checking done on the values. If we wanted to do that, we'd have to hand-
 add all specfile locations or do some scary recursive directory search.

 Therefore I propose to put *all* spec files in the source tree in one
 specific directory (like they would be when installed), so the manager can
 simply read all of them out, and the modules only need to know the file
 name, not the location.

 This would also be a nice first step to have 'offline' access to these
 things (the API that loadzone would (perhaps indirectly) use for instance)

-- 
Ticket URL: <https://bind10.isc.org/ticket/243>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development