[Haskell-cafe] Reactive config file generation

[David Turner]

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.

Many thanks,

David




On 19 August 2015 at 17:12, Heinrich Apfelmus <apfelmus at quantentunnel.de>
wrote:

> Hello David,
>
> author of the FRP library "reactive-banana"[1] 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" [2], which is very similar. There are also two very
> recent offerings, "reflex" [3] and "frpnow" [4]. I don't know much about
> the former. The latter has a nice theory background, but seems to be
> pull-based.
>
>
> Best regards,
> Heinrich Apfelmus
>
>   [1]: https://wiki.haskell.org/Reactive-banana
>   [2]: https://hackage.haskell.org/package/sodium
>   [3]: https://hackage.haskell.org/package/reflex
>   [4]: https://hackage.haskell.org/package/frpnow
>
> --
> http://apfelmus.nfshost.com
>
>
> 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
>> node
>> 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
>> done.
>>
>> 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
>> hand
>> 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,
>>
>> David
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150821/77fe63f8/attachment-0001.html>