[bind10-dev] Summary of configuration / cc-channel discussions

[Jelte Jansen]

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

Michael Graff wrote:
> Michael Graff wrote:
>> Jelte is going to look into
> 
> ... YANG to see if it would be useful to us outside of NETCONF.  It
> might be able to generate some classes for interface work for instance.
>  I proposed that we quickly look at other IDLs as well, which may be
> better suited to this than YANG, which we would have to mostly write
> from scratch.
> 

What i would like to have is something to automate at least the
configuration data classes. Normally we write something and data that
needs to be configured is written as we go along, and each time it is
mostly the same; some set of values, with some range limitations, and
some accessor functions, followed by a way to store and retrieve them,
and perhaps a way to communicate them.

Like the UML people have realized, this could be done automatically. What
i had made in experiments/ initially was a different approach for this,
a very general structure where you can place anything in. But you still
need to have a model around it. What i would like to see is some
definition of the data that a component needs, and automatically create
classes for it, with a fixed API around it.

For instance if we have some container that contains a certain string
value named foo, the component using it could do
container.getFoo() (as opposed to getProperty("foo") for instance), this
would give a bit of compile-time checking on access to the model.

Taking this a step further, if we have a communication system ready, we
may be able to integrate that seamlessly (although i don't know if and
how we would do that at this point). Perhaps a bit like in the RMI world
with stubs and skeletons.

(all of this to let us focus on the logic when building the components)

If we go this way, we need some description language and a tool to
generate that part of the code.

The description language would have to have support for:
- - basic types (int, bool, string)
- - lists (and perhaps named hashes), and selections
- - complex types (composing of basic types, lists, and other complex types)
- - ranges for values, for automatic checking

The resulting classes would consist of
- - structures to contain the data
- - getters and setters for that data
- - a way to store/retrieve the data
- - a way to synchronize the data with some other process (so it can be stored
centrally)


Note that this consists only of specific configuration data, optionally
one could also contain run-time data (statistics) and operations on that
data. But by then we might as well handcode it anyway...

This is what got me looking at YANG. Which seems nice, even though the
spec isn't finished yet. But like netconf, it is probably a bit overkill;
not only can it also define RPCs and notifications, they've gone through
quite a bit of trouble adding support for extending existing models, and
adding stuff like typedefs, grouping, and 'value-must' rules, which all make at
least a generalized parser/generator quite a bit more complicated than
necessary. We could of course take only a part from it but we'd still be
defining our own thing then.

So YANG is part data-model-language, part IDL. I've done a quick search on
other IDLs and generators, but so far haven't really found anything that looks
useful yet.

Thoughts are welcome :)

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

iEYEARECAAYFAkqqQXYACgkQ4nZCKsdOncVvGgCeIBtRykpA0z4SYHNuvnEMEviD
jDkAn0C+eZCc1NzEsy+Yn3RlLtUHaxKz
=4EN+
-----END PGP SIGNATURE-----