[bind10-dev] config data api

[Jelte Jansen]

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

On 04/13/2012 12:13 PM, Michal 'vorner' Vaner wrote:
> Hello
> 
> On Fri, Apr 13, 2012 at 11:06:58AM +0200, Jelte Jansen wrote:
>> i suspect that this would be needlessly complicated, both in
>> terms of implementation and in use; if you update one value you
>> wouldn't expect a seemingly 'remote' value to be change as well.
> 
> Huh? I don't get this. What I mean is just saying that this
> module's name is '/Auth/NameOfPlugin' instead of '/NameOfPlugin' so
> the path corresponds more to logical grouping together than to
> implementation. Because now a module can probably add its own
> config through yet another spec file, but it can't embed its values
> inside the current spec.
> 

ah, sorry, I thought you meant you could map any location to any other
location. Yes we could add grouping like that, would probably be nice
not to have 40 'top-levels' at some point :)

> 
> It would indeed be nice, but I don't think it would be practical to
> switch now. Anyway, if the type would be used by that module only,
> we wouldn't need dynamic loading for it. We would need: * The
> module to register the type in its copy of the CC library at
> startup. This can be linked statically without problems into the
> module itself. * Python implementation of the type, so the bindctl
> and config manager can handle it.
> 
> No other C++ module would come in contact with the value, so it
> should be safe. But in case it still does, we could pretend there's
> a fallback type (like presenting it as a string).
> 

true, sounds like a good idea
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+H/1QACgkQ4nZCKsdOncW9EwCeKPIrIO4SHg+mDtGPLla079B0
bpIAoJXX/bjVkLYc5+++55425SwiLlcr
=BGGo
-----END PGP SIGNATURE-----