Muontrap.Daemon Proposal about muontrap HOT 8 OPEN

Hi @alde103 - That seems like a good feature to add. Perhaps it's a configuration key that specifies a callback and the default callback is to log the message. For your use case, you'd pass a function that sends a message. What do you think of that?

from muontrap.

I'm interested in this as well! Was thinking about hacking the into to pass a collectible that I implement with a callback

from muontrap.

Adding an :into option to MuonTrap.Daemon.start_link sounds like a really good idea.

from muontrap.

Hi all,

@fhunleth, Which one do you like best?

• Use the using macro with the whole @callback ceremony (the default callback would be logging it).
• Use a key (:into) in the state for the callback function (anonymous function) that is called every time there is a new message (default the log function).

from muontrap.

Hi @fhunleth, Would you be interested in Muontrap.Daemon.Server??, it would be a module that implements a behaviour that wraps MuonTrap.Daemon for handling daemon messages with GenServer's states.

from muontrap.

I'm not sure about Muontrap.Daemon.Server. It feels like there should be other ways of accomplishing the same thing that require significantly less code:

1. Create your own GenServer that runs the muontrap port binary like Muontrap.Daemon, but has your custom code.
2. Have Muontrap.Daemon emit telemetry events and attach to those. I feel like we're exploring that the PR. I'm also exploring this in another library and will hopefully have stronger opinions on :telemetry soon.
3. Write a GenServer to monitor your Muontrap.Daemon GenServer that you want to run some code when it exits.

Could you talk about your use case? Perhaps that will help me understand better.

from muontrap.

In short, my application will run a configurable number of unspecified daemons (configurable at runtime), whose logs/outputs will be processed based on runtime configurable Regex and are propagated to the rest of the application.

And as you mention, my current approach is to use (1) but I think some features of MuonTrap.Daemon are desirable to make the application more scalable.

Also, I would like to reduce the ceremonial code to the final user, which is one of Muontrap.Daemon.Server purposes.

Muontrap.Daemon.Server could be restructured so that instead of relying on direct messages from MuonTrap.Daemon, it would use telemetry events.

from muontrap.

Hi, I was recommended this project today (which is great!) but I also ran into this limitation.

I don't know if anything has changed since this discussion, but could this be solved by supplying an optional log_fn/1 to the Daemon? This would allow us to add custom log-processing logic in a relatively straightforward way.

from muontrap.