[bind10-dev] config data api

Michal 'vorner' Vaner michal.vaner at nic.cz
Fri Apr 13 10:13:37 UTC 2012


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.

> ...and this is a point where i wish we had done everything in python,
> and *only* do critical-code-paths in c++ as python modules. In which
> case the answer would've been yes. As it stands, we could, but I'm not
> sure whether adding yet another loadable module point would be worth it.

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).

With regards

-- 
grep me no patterns and I'll tell you no lines.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20120413/9ed7eb61/attachment.bin>


More information about the bind10-dev mailing list