logger icon indicating copy to clipboard operation
logger copied to clipboard

Dynamically add log handlers

Open k0ral opened this issue 10 years ago • 6 comments

The current API forces one to choose the log backend once and for all when runLoggingT is called. This may be undesirable, as you may want to add new log handlers dynamically afterwards.

The solution I'm currently using is to feed a broadcast TChan as a log backend, to which I can dynamically subscribe in as many log handlers as I want.

This is quite boilerplate as it seems monad-logger wasn't designed to be used in such a way, so I'm wondering: would you consider augmenting monad-logger to handle/facilitate that use case ?

Thank you.

k0ral avatar Feb 18 '15 10:02 k0ral

I would probably just store the log function in a mutable variable like am IORef and read the function every time logging is necessary. Would that approach work for you?

snoyberg avatar Feb 18 '15 11:02 snoyberg

That approach would work (though I would use a TVar rather than an IORef) but has a drawback. My analysis is the following:

  • either you want MonadLogger to handle log messages by itself, in which case it must own the handler function(s); that's your approach with an IORef;
    • advantage: the MonadLogger instance holds the log handlers, constraints can be enforced on their type
    • drawback: log handlers can't live in an arbitrary monad stack (the moment runLoggingT is called fixes once and for all the monad stack of all handlers)
  • or you want MonadLogger to simply publish log events and let external log handlers subscribe to them; that's my approach with a broadcast TChan;
    • advantage: log handlers can live in arbitrary monad stacks
    • drawback: the MonadLogger instance has no control whatsoever on the log handlers

What do you think ?

k0ral avatar Feb 18 '15 12:02 k0ral

I don't see the distinction you're making. MonadLogger is quite generic; you can use any kind of action for publishing log messages. Putting them into a TChan or writing to a Handle is IMO the same concept. I'm not sure what additions to the library you're looking for.

snoyberg avatar Feb 18 '15 13:02 snoyberg

I'm simply asking whether you would consider adding some higher-level features to monad-logger, like log handlers management. Currently, it's up to the library user to implement publish-subscribe, I figured maybe integrating it within monad-logger made sense as it is a common pattern. The above analysis was about 2 ways to implement it. I'm not sure myself that this is a good idea, but I wanted to raise it.

k0ral avatar Feb 18 '15 17:02 k0ral

The answer to that is that no, I'm not opposed in principle to adding new functionality. To clarify my previous points though: I'm not sure based on our conversation so far what the goal of such functionality would be or what it would look like.

On Wed, Feb 18, 2015, 7:06 PM k0ral [email protected] wrote:

I'm simply asking whether you would consider adding some higher-level features to monad-logger, like log handlers management. Currently, it's up to the library user to implement publish-subscribe, I figured maybe integrating it within monad-logger made sense as it is a common pattern. The above analysis was about 2 ways to implement it. I'm not sure myself that this is a good idea, but I wanted to raise it.

— Reply to this email directly or view it on GitHub https://github.com/kazu-yamamoto/logger/issues/54#issuecomment-74903018.

snoyberg avatar Feb 18 '15 17:02 snoyberg

The goal is to be able to dynamically add/remove log handlers at runtime. It could look like that: a distinct typeclass that offers a addHandler function (but this is just an example, you may want to design it differently).

k0ral avatar Feb 20 '15 11:02 k0ral