Re: Supervisor and configuration update — how to do it?

[Michael Truog]

On 5/19/20 10:36 PM, Max Lapshin wrote:
> Hi.
>
> Our flussonic has big amount of code related to smooth configuration
> update. Almost all configuration parameters can be changed on fly: it
> is very important, because we handle big amounts of video traffic.  It
> is very bad to leave 20 000 people without video if you want to
> reconfigure single channel.
>
>
> We have to fight with supervisor concepts: we do not accept
> configuration in start_link/init, because it may change later.
I prefer putting configuration in start_link/init and changing it with a 
message.  That keeps the approach functional, pursuing referential 
transparency, making sure the update of the configuration info is not 
error-prone because the sequence for the update gets well represented in 
a sequence of functions that are called (easy to test, easy to add 
asserts to, easy to reason about and make assumptions about).  I am 
assuming you don't use the process dictionary.  Things are normally not 
completely referentially transparent due to catching exceptions and 
messages getting received, but often that processing is isolated in 
function calls for that purpose.

I understand the tendency to pursue ets, mnesia, persistent_term or a 
global data store for (transient read-write) configuration, because that 
approach seems easy with mutable data and time is spent trying to ignore 
the data inconsistency problems that occur as things change.  Arguing 
for global data is similar to arguing about the benefits of global 
variables and imperative programming, so often people coming from an 
imperative programming background will feel compelled to find a way to 
use global data to solve problems. Its best to resist this temptation in 
a language that supports functional programming.

Best Regards,
Michael