[bind10-dev] config experiment 2

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

JINMEI Tatuya / 神明達哉 wrote:
> Here are some random comments about the experimental implementation.
> Some of them may be too detailed at this stage.  If so, please feel
> free to ignore them.

not at all, thanks :)

> 
> - Just a question: do we assume the use of XML or some tree structure
>   as part the API spec?  At least methods like "addChild()" indicates
>   the configuration is stored in some tree structure.  But if we
>   possibly change the internal representation in the future, we might
>   want to provide a more generalized interface.  Note: I'm not
>   suggesting it, just wondering.
> 

i've renamed the public _child() functions to _element(), which i think better
conveys the purpose as opposed to the internal structure.

> - we'll also need to be able to remove an element(s)?
> 

added remove_element(identifier);

> - if the configuration is stored in a remote server, would we specify
>   it as part of the IDENTIFIER (such as a URI) and use the same API
>   like getValue()?  If so, it probably makes sense, but the remote
>   version of the call could "block", right?  Should we consider how to
>   handle blocking operations for these interfaces?
> 

yes, i haven't looked at the messaging stuff yet, but the handler of that ties
in with this.

> - getConfigPart() requires the caller to delete its return value,
>   assuming getConfigPart() allocates memory using new.  I think such
>   an implicit requirement should be avoided.  
> 

hmm, see my response to the exception thing below

> - would we like to provide an accessor (get/set) to a specific config
>   node (element)?
> 

set/get_config_part do this, or i don't understand what it is you mean here

> - I didn't understand this method:
>         /*
>          * Adds an empty element to the children of the current node
>          */
>         void addChild(std::string name);
> 
>   what's the "current" node?  do you mean the base (root) node?  Or is
>   this an arbitrary node in the tree determined by some context?  BTW,
>   in general, should we treat the base node separately?  That is,
>   since we could specify the path to the base node and use the more
>   generic version of methods, aren't the "base-only" methods
>   redundant?   (even if so I'm not necessarily objecting to it; if,
>   for example, operations on the base node is much more common, it
>   would make sense to provide convenient shortcuts)
> 

I don't handle the root node separately; the api functions are agnostic as to
which part of the whole tree you are currently using; while everything could be
done with

a = get_config_part(identifier)
a->setValue(b)

the identifier based parts are shortcuts;

setValue(identifier, b);

you could also see the configpart as a shortcut, if you need to do a lot of
operations on a specific part, you only need to provide the identifier once

the context you mention would be the identifier with which you first get the
config part. This is kind of based on the mozilla system; a module usually only
concerns itself with its own subset of all values, and it doesn't need to
specify over and over again where in the full tree that part lives

> - use of exception:
>  * If the element or node is not found, usually a ConfigError exception
>  * is thrown.
>  I myself don't necessarily object to this approach, but I thought we
>  previously loosely agreed we don't use exceptions for "expected
>  exceptions", that is, non-bug exceptional events.  for example, we
>  wouldn't throw an exception if we receive a malformed DNS message.
>  Likewise, we'd handle it as a normal event if a user mistype a config
>  parameter.  Again, I don't stick to this policy (or I may
>  misunderstand the previous consensus), and I'm open to other
>  approaches.  But in any case, I think we should have some common
>  guideline on how/when to use exceptions.
> 

I agree that always throwing an exception here isn't right, but i'm not sure we
are all in sync in when to do throw one.

IMHO, a user making a typo when specifying an identifier directly it should be
an exception (as opposed to the user specifying a correct identifier which is
optional and happens to not exist, in which case no exception should be thrown).

yes, that would mean that it is also my opinion that unrecoverable malformed DNS
messages should result in an exception from the parser as well;


(snip rest of your comments, all good points, and done)

(except one)
> - style issue: would we allow C-style comments?
> 

dunno, i like em, but no problem for me to go c++ only.

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrLGyAACgkQ4nZCKsdOncXYHACfUP+ql3qPXxECL4pIYBntAlJQ
YJgAn0j9yDayGh0+Bv9mN+RsJF56pfPw
=lGqm
-----END PGP SIGNATURE-----