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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe