[bind10-dev] config experiment

[Jelte Jansen]

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

JINMEI Tatuya / 神明達哉 wrote:
> At Thu, 03 Sep 2009 15:29:02 +0200,
> Jelte Jansen <jelte at isc.org> wrote:
> 
>> There are still quite some open issues, how to do integrity and transactions,
>> defaults, and constraints. And of course how to fit all types of config data
>> into this structure. I have some ideas for most of these, but it might be time
>> for a bit of discussion about the direction in general, and the stuff so far
>> first :)
> 
> This generally seems reasonable to me.
> 
> One minor comment about the interface/experimental implementation: we
> may want to make the on-change/can-change interfaces more
> object-oriented style, that is, let objects register themselves with
> an entry they are interested in so that they can be notified later,
> rather than installing a "callback function".
> 
> BTW: are these notifications supposed to be delivered via
> "communication channels"?  If so, the interface may also need to be
> generalized accordingly (I don't have a specific image about how it
> looks like, though).
> 


i've been thinking a bit on another approach, based on the
specification-language stuff i sent in
https://lists.isc.org/pipermail/bind10-dev/2009-September/000113.html

if we think of something like this

+-------+                           +------+
|BigTool|<-\        +-------+ /---->|module|
+-------+   \       |config |/      +------+
             REST-->|manager|\
+-------+   /       +-------+ \     +------+
|otherUI|<-/            |      \--->|module|
+-------+               |       \   +------+
                  +----------+   \
                  |persistent|    \ +------+
                  |config    |     >|module|
                  |store     |      +------+
                  +----------+


What we could do is make a little tool that takes such a language, and generates
a skeleton for inclusion in the central configuration manager, and a stub for
use in the module you're creating. Exactly how the communication between those
components would then happen is hidden for the module implementer (either
'local-copy + register-and-get-notifies' or perhaps even directly asking for
them when needed, but that may be too much runtime overhead).

If we would go that route, depending on how we make the manager, inclusion of
the skeleton would mean recompiling it, unless we actually do the configuration
manager in some interpreted language that can easily include new code, or make
some scary dynamic library setup for it. The skeleton could also contain
persistency logic, hiding that as well for the implementer.

For the module part, the generator could build something with a predictable API
that simply needs to be included in the module (as in if the model contains a
field 'data' it would make a getData()), in the language of choice of the module
writer.

And then, if we think this could be more complicated, the specification could
contain more complicated constraints (like dependencies), and or information on
how to interact with that data (like capabilities, or simplified commands that
update multiple data points).

Ultimately, it would be great if the module writer can focus as much as possible
on the logic and not on boring stuff like communication and configuration :)

Jelte

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

iEYEARECAAYFAkqwszUACgkQ4nZCKsdOncWzSACfWt88BMAgSkiG/G69wPmJu0cB
JDEAn0geMUYcWWmztcXauQZohYd87cNk
=5R1J
-----END PGP SIGNATURE-----