Serge,<br><br>Thanks for your reply.<br><br><div class="gmail_quote">On Tue, Dec 2, 2008 at 11:08 PM, Serge Aleynikov <span dir="ltr"><<a href="mailto:saleyn@gmail.com">saleyn@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Note that there's already a config_change callback in the OTP application behavior that can be used as a notification mechanism.<br>
<br>
This post illustrates a way to reload the application's configuration and trigger the config_change callback so that the application can perform dynamic reconfiguration without restarting:<br>
<br>
<a href="http://www.erlang.org/pipermail/erlang-questions/2006-July/021543.html" target="_blank">http://www.erlang.org/pipermail/erlang-questions/2006-July/021543.html</a><br>
</blockquote><div><br>That's very interesting. I had seen config_change before while looking for something else in the application module, but I seem to develop a kind of "tunnel vision" that focuses on what I need to know right NOW and skips over other details, so I hadn't paid it much attention and frankly forgot about it until now. There's SO much to remember in Erlang (and any major environment like it). Something that would have put me off track is the documentation that states "This function is called by an application after a code
replacement, if there are any changes to the configuration
parameters." I would have thought a code replacement was necessary, so your insight is very welcome.<br><br>I assume, reading the code you linked to, that one still needs to include in the config_change callback something to propagate the changes to the various workers and supervisors. Do you think that the subscribe/notify mechanism I described is workable?<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
This is a simplistic approach that doesn't involve configuration validation.  Actually this was a part of a configuration management framework that we developed at my former employer that included a configuration server that maintained the versioned configuration repository that also performed syntax verification based on the application's metadata deployed with each app that included all needed parameters for each environment type (e.g. prod/dev/qa/etc), parameter types, defaults, update actions (such as reload environment, restart application, restart node, etc.), parameter documentation.  The server would perform configuration validation based on this metadata and reject unconformable input.  Each node would run a configuration client that upon startup would query the configuration server and rebuild the local configuration file if there were any parameter changes.  It would then use that configuration file in starting a release.</blockquote>
<div><br>That's pretty sophisticated and along the lines of what I had envisioned. It's a pity I don't have the time to write something like that. Your former employer was evidently unlucky to lose you :)<br><br>
Do you by any chance remember if the metadata was able to describe complex terms involving nested lists and tuples? Also, do you know of something like type_of(Term) (besides is_integer/1 and the others) available somewhere in Erlang?<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Regards,<br>
<br>
Serge<br>
</blockquote></div><br>