Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamically add log handlers #54

Open
k0ral opened this issue Feb 18, 2015 · 6 comments
Open

Dynamically add log handlers #54

k0ral opened this issue Feb 18, 2015 · 6 comments

Comments

@k0ral
Copy link

k0ral commented Feb 18, 2015

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.

@snoyberg
Copy link
Collaborator

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?

@k0ral
Copy link
Author

k0ral commented Feb 18, 2015

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 ?

@snoyberg
Copy link
Collaborator

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.

@k0ral
Copy link
Author

k0ral commented Feb 18, 2015

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.

@snoyberg
Copy link
Collaborator

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
#54 (comment).

@k0ral
Copy link
Author

k0ral commented Feb 20, 2015

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants