logger
logger copied to clipboard
Dynamically add log handlers
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.
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?
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 anIORef
;- 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)
- advantage: the
- or you want
MonadLogger
to simply publish log events and let external log handlers subscribe to them; that's my approach with a broadcastTChan
;- 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 ?
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.
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.
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.
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).