[bind10-dev] config data api

[JINMEI Tatuya / 神明達哉]

At Thu, 12 Apr 2012 16:38:07 +0200,
Jelte Jansen <jelte at isc.org> wrote:

> So, initial requirements braindump:
> 
> - - need to be able to represent ?changes? (modifications, additions,
> removals)
> - - need to be able to count on content structure (i.e. data must be
> validated according to .spec file, and to check whether it has been
> validated)
> - - need to be able to easily access ?actual? data (i.e. custom setting
> or default)
> - - need to be able to check whether the value was default
> - - need to be able to override some values for in-source use
> - - need to be able to access ?deeper? parts of the structure, both
> directly as children from an element and an ?absolute? and relative
> ?path? in the data (e.g. the current identifier functions, and
> Element::find())
> - - identifiers must support (nested) maps, and (nested) lists
> - - possibly: case insensitivity in identifiers?
> - - we need extensible/additional ?types? (e.g. IP address, domain name)
> - - while we are at it, we should clarify or redefine ?optional? and
> ?default? values

Not fully thought about this topic, and admittedly not fully
understood the proposals, but providing some feedback...

What I've found inconvenient or confusing was
- it's not easy to get access to the default values
- it's not clear (at least to me) how applications should expect
  config differences are provided.  For example, if there's a list of
  zones (for some purpose) and the admin adds or deletes one zone
  to/from the list, how the application is expected to be notified of
  it?  I also wonder the efficiency considerations of this operation
  especially if the list is very large - this also leads to
  how/whether we handle large scale data using the current config+msgq
  framework.
- it's not clear who is responsible for validating data.  So sometimes
  the application could do redundant checks, and sometimes the
  neceessary checks could be missing, leaving the application
  fragile.  This may be a documentation issue rather than design,
  though.  It would help if we have a big picture (probably literally
  with a drawing) of the relationship between related
  components/modules/libraries in terms of who is responsible for what
  kind of validation, and what's the assumption for each module in
  terms of data validation.

From a quick read of the proposals, some points seem to be in
consideration, and some may not.

Another topic: I wonder whether we can share more code regarding
config data for C++ and Python.  Right now we implement many related
features in both languages separately, slightly with different
capabilities.  This is both inefficient in terms of development and
maintenance, and one main source of confusion.

---
JINMEI, Tatuya