[erlang-questions] Configuration management below the application layer?

[Joern]

Hi Daniel,

On 8/15/07, Daniel Goertzen <daniel.goertzen@REDACTED> wrote:

> So the main difference with mine is that there are no requirements on the
> client processes, and the reaction-to-configuration-change
> policy is embodied in the client processes rather than the config server...
> it works well for me, put perhaps your needs are different?

My needs are probably not that different - except that in my case some
kind of plain text configuration file is a requirement. Of course I
could easily adopt your excellent suggestion, write this data on
demand into an mnesia table to which the interested processes
subscribe.

The problem I saw with such an approach is that I would have need a
considerable amount of infrastructure for unit tests. That's why I
initially opted for an approach which embedded the config data into a
behaviours state.

On the other hand one could probably combine both approaches by
handling the configuration in mnesia AND keeping the current config in
the behaviours state - the actual mnesia event subscription could be a
fun() in the state or the (then abstract) module. This would allow one
to simply mock out the wait for mnesia / initial pull of the
configuration and the subscription to changes from the mnesia
database.

> Getting back to your approach... instead of extending each configurable
> module with a pile of handle_info clauses, you could implement a
> supervisor-like module to receive the configuration messages and restart the
> actual configurable module based on that.  One config-supervisor process per
> configurable process.

That's another quite good idea. Currently I just { stop, ... } with
reason configuration_changed my persistent processes and let their
respective supervisor restart them. But the whole discussion makes me
wonder nevertheless - is the configuration of processes such a unique
problem?

Best regards,


Joern
--