[Haskell-cafe] Reactive config file generation
dct25-561bs at mythic-beasts.com
Thu Aug 20 23:47:51 UTC 2015
Hi Heinrich (and other helpful souls),
Thanks for the replies. I started out this response with an attempt to give
more detail in the hope of explaining why I thought this was rather more
complicated than it first appears: at least, applying a new config is
expensive so idempotence isn't very helpful.
However, in the process of writing this I came to the conclusion that there
is a rather simple, if slightly inelegant solution. I can write some code
which generates the initial config and also logs what nodes in ZK were read
or enumerated; by keeping this log I can watch for updates and if anything
is updated then I can re-generate the whole config, compare it for equality
against the previous config, and apply the new config if needs be.
I call this slightly inelegant because I was kind of hoping to be able to
re-run just the part of the config-generation function that was downstream
of the update that fired. On reflection, this seems unnecessarily frugal -
these are not large configs I'm dealing with, so not worth much effort to
cut out the extra computation.
I suppose this is in some sense a poor-man FRP? But it'll do for me and
does seem rather simple.
On 19 August 2015 at 17:12, Heinrich Apfelmus <apfelmus at quantentunnel.de>
> Hello David,
> author of the FRP library "reactive-banana" here.
> Well, you can certainly use FRP in this context, but your situation seems
> so simple that I'm not sure if it's worth it here. The way I see FRP is
> that it helps you deal with time-varying state in a way that does not lead
> to spaghetti code. The fundamental insight is a semantic one, but on the
> practical side, FRP simplifies change propagation and reasoning about the
> order of changes.
> Your situation looks like you do not have to keep track of state, i.e.
> most of your operations seem to be pure or idempotent, so while FRP won't
> hurt it, it won't make your life significantly easier either.
> On the question of choosing a library, I would, of course, recommend
> "reactive-banana", but I may be a little biased there. :) I can also
> recommend "sodium" , which is very similar. There are also two very
> recent offerings, "reflex"  and "frpnow" . I don't know much about
> the former. The latter has a nice theory background, but seems to be
> Best regards,
> Heinrich Apfelmus
> : https://wiki.haskell.org/Reactive-banana
> : https://hackage.haskell.org/package/sodium
> : https://hackage.haskell.org/package/reflex
> : https://hackage.haskell.org/package/frpnow
> David Turner wrote:
>> Hi all,
>> I am using Apache Zookeeper as a service directory: I have a bunch of
>> services which announce their presence by making nodes in Zookeeper, so
>> that dependent services can update their configuration to make use of the
>> available services, and stop trying to use services that have died.
>> Zookeeper is a pretty nice fit for this because it supports watching a
>> for changes, so in theory there is no need to poll Zookeeper periodically.
>> The services that I control work with this just fine, but there are some
>> (e.g. an Nginx reverse-proxy) that are reconfigured using the rather more
>> common approach of updating a file (or files) and then sending the process
>> a signal. I am currently pondering how to make this work without polling,
>> or manually triggering a refresh script, which is how it is currently
>> I've never used FRP, but am at least vaguely aware of it and from my
>> high-level understanding it seems like this could be a very good fit. The
>> Zookeeper state is a time-varying value which I want to convert into a
>> time-varying set of files, ideally as declaratively as possible.
>> So, two questions to the FRP congnoscenti out there. Firstly, is it
>> worthwhile to attempt this using FRP at all? I'm sure I could do it by
>> too. Secondly, which of the many FRP libraries would you recommend for it?
>> There are loads on the Wiki, seemingly in various states of repair and
>> documentation. Any pointers on how to choose one that's featureful enough,
>> performant enough, and being actively maintained?
>> Thanks in advance,
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe