Closed RaoulHC closed 4 years ago
No reason for the Maybe
in option 2; id
can be used to skip formatting.
I'm OK with this change if you'd like to open a PR.
At some point, someone who's enthusiastic about logging should probably take a holistic look at rio's logging system and propose wider-ranging improvements. But this seems like a reasonable extension.
At some point, someone who's enthusiastic about logging should probably take a holistic look at rio's logging system and propose wider-ranging improvements. But this seems like a reasonable extension.
I wonder if it'd be worth moving some of the methods over to an internal logging module too, at the moment it feels like some of the inflexibility is from not being able to access some of the internal methods. For example having access to the LogFunc
data constructor would make it a lot easier to pass in custom log functions.
It would be good to be able to add extra project specific information to log functions, to add context information automatically. For example, in a current project I'm working on, I have several threads open to manage network connections and it would be good to add which address a log message is referring to. Currently a lot of the methods to access these parts of a
LogFunc
are private, making it hard to customise as much as I'd like in a project.I think this could be implemented by adding a method to format the
Utf8Builder
by either:unLogFunc
to format the message sent. This would just change the message that's sent tologGeneric
. This does mean to use withwithLogFunc
you'd need to transform it before embedding it in the monad.LogOptions
that formats theUtf8Builder
, whichlogGeneric
could call on the message first, before calling the actual log function. Could belogFormat :: !(Maybe (Utf8Builder -> Utf8Builder))
Let me know if you think any of these are a good idea (or if I'm missing some other way of going about this!) and I'll have a go at getting a PR up.