Expose Haskell Library/API for advanced cases

[ozataman]

I thought this may be another very cool addition: Use the same underlying infrastructure to expose a Haskell DSL that allows one to write Haskell code instead of the config file. You would compile the config file into an executable that does the watching.

This would certainly be for the more advanced use cases or when re-usability/modularity pays off due to a large deployment.

Here are some capabilities this would bring:

• High modularity - Haskell functions are inherently highly reusable
• Determine some configuration parameters dynamically at run-time (ask a database for which and how many processes should be live)
• Implement custom load throttling - scale up/down processes based on CPU/memory availability
• Implement more sophisticated restart patterns (exponential backoff, etc.)
• Signal other entities as up/down events happen

[MichaelXavier]

I think this is a much more tractable problem. I think this may also make more sense in the rewrite I'm playing with. That one is written using MVC which reorganizes it into an event layer (program death, new configs, etc). I could see providing this as an API with a default implementation (watch a file for config changes) so that you could swap in an event source (called a controller in MVC) that instead generates configs instead of reading a file. I definitely don't want to move the default use case to a turing complete config language. I've seen a lot of projects turn into outright disasters by going down that tempting road.