[bind10-dev] config experiment 2

[Jelte Jansen]

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

JINMEI Tatuya / 神明達哉 wrote:
>>> - 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
> 
> Ah, I realized I misunderstood the API a bit, but the main point when
> I mad this comment still stands, which is this: since
> get_config_part() makes a copy of the original configuration, if we
> want to modify that part of the config we need to do set_config_part
> explicitly.  But one may rather want to do something like this:
> 
>   config->get_config_part2("/module").set_value("foo");
>   (get_config_part2() returns a reference to the corresponding config
>   element of the original config tree)
> 
> to update the value of the "/module" part of the original config.
> 
> Perhaps a principal policy of how to change the configuration is "get
> a local copy, modify it, and then commit it".  If that is the policy I
> see the design of the current API and I'm fine with that.
> 

yeah, actually i kind of did it this way to reflect the manner in which another
process (like a UI client) would modify the data in the configuration, where it
would be a copy anyway, and so we can have multiple changes all 'committed' at
once (although there isn't really anything atm that does transaction-like
things). But having direct access makes more sense for the internals of the manager.

>>> - 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
> 
> I saw it, but I'm not sure if this comment is to be discussed in that
> context.  My point is that this interface is an easy source of memory
> leak.  Admittedly this is probably a matter of coding style
> preference, but I'd personally like to:
> 

my bad, I planned on going into it a bit but then got into another train of
thought when talking about exceptions.

What i was originally thinking was that one would either have a pointer to
return NULL if the requested field was empty or non-existent, let the caller
initialize it and pass it along, or use exceptions for all errors where there
would be nothing to return. But I hadn't thought about RAAI and shared pointers
yet for this. I'll think about your suggestions.

>>> - use of exception:
> 
>> 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.
>>
> I also agree that we don't necessarily have to have a strict policy of
> when/how to (not) use exceptions.  Still, I think it's better to have
> a general guideline to make the overall coding style consistent (which
> I believe helps improve code maintainability).
> 

yes.

> This should probably be discussed in a more generic context.  I'll
> send a separate message focusing on this topic later.
> 

I was just thinking the same thing :)

>>> - style issue: would we allow C-style comments?
>> dunno, i like em, but no problem for me to go c++ only.
> 
> This is also an open topic, and we might rather not bother to do with
> this level of minor style policy; however, I'd still like to make the
> style as consistent as possible if we can easily reach a consensus.
> This is also probably a general discussion item.  (I've noted this
> point in the wiki, too)
> 

I fully agree.

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

iEYEARECAAYFAkrNoToACgkQ4nZCKsdOncUHFQCgvkZUV1A0ct9ZusDWp6aCYdm9
OxIAniVp4u90j2jNZfLnJZ3duNlwVNea
=Ly4E
-----END PGP SIGNATURE-----