Feature Request: Varied Granularity Option for Multiplexed Loggers about swift-log HOT 4 CLOSED

I absolutely agree but also think that's perhaps one of those things that should be done in a good logging library / "backend implementation" -- and this is just the "API" package. We should not allow this package to keep absorbing more features (arguably it already does too much... which is why things like this come up, since this package did something, but could left a complete void to be filled in), WDYT?

Kind of looking forward to a bells-and-whistles backend to happen, like http://logback.qos.ch/manual/index.html does for http://www.slf4j.org (where apple/swift-log is "like slf4j", "just the API")

from swift-log.

I'd agree that feature sprawl is dangerous but the only real difference between the current Multiplex is that you'd have a version that sorts the handlers it's initialized with in order of increasing priority.

EG, in the example -

• logging a .critical would skip the first two handlers and just be passed to the third
• logging an .info would hit the first two and short circuit on the third
• logging .debug would short-circuit immediately

Note that I'm not saying the package should handle anything about WHERE the errors go (the example handlers would still be implementation-dependant and up to the user to put together) - it simply makes decisions based on the user's configuration that's provided to it. And if anything it seems like it would be less appropriate to shim together something like this into a single handler, since it operates on nothing but info the base system already knows about (and is responsible for defining!)

from swift-log.

I'm linking my thoughts of why SwiftLog is so basic here. @tdotclare are you happy closing this as "not for the API package"?

from swift-log.

Man, I'd totally forgotten about this. Closing!

from swift-log.