Change name from TeeLogger?

[oxinabox]

When I came up with the name DemuxLogger,
I was thinking that it would do the routing itself.
Taking in both rules, and loggers.

But it is easier to just leave the rules to the filtered logger.

I am not sure what is a better name for this

[c42f]

Possibilities...

• SplittingLogger?
• TeeLogger — in analogy with the unix tee for pipes?

[oxinabox]

Go's log15 library calls this a Multihandler https://github.com/inconshreveable/log15/blob/master/handler.go#L200
Along those lines we would call it a MultiLogger
Which is not bad

[c42f]

+1 for MultiLogger

[tkf]

I'm +1 for TeeLogger, as I can imagine another logger wrapping multiple loggers that uses the fist matched logger. It can be used as, e.g., SwitchLogger(ProgressLogger(...), TBLogger(...), global_logger()), to let special loggers handle special log events. To be more precise, the implementation would be something like

function handle_message(logger::SwitchLogger, args...; kwargs...)
    i = findfirst(l -> comp_shouldlog(l, args...), logger.logging)
    i === nothing && return
    return handle_message(logger.logging[i], args...; kwargs...)
end

[oxinabox]

I would not call that SwitchLogger but it is beyond the scope of this Issue.

[tkf]

The main reason I brought this up was to highlight that the name MultiLogger does not specify the functionality uniquely.

[c42f]

As noted on #22, I'm fine with the name TeeLogger, but neither do I really love it in the sense that I can't yet see it's an "obviously right" consistent and clear choice.

In particular, considering Mux vs Demux naming, what would be the equivalent of Mux? A "tee" can either join or split the flow; there's nothing in the naming to suggest which we are doing. (Though there's the analogy to the unix pipe utility tee which is a splitting tee.) But maybe this is a non-issue, given that the current design is "sink-centric" in the sense that any AbstractLogger needs a handle_message, and therefore can act to join several log streams.

I did like MultiLogger but @tkf's point in #1 (comment) seems somewhat convincing.

[tkf]

As noted on #22, I'm fine with the name TeeLogger, but neither do I really love it in the sense that I can't yet see it's an "obviously right" consistent and clear choice.

Actually my +1 to TeeLogger is similar. I'm not sure if I thought it was obvious if I didn't know the tee command.

I think that DemuxLogger can be characterized as a logger that sends the message to all child/inner loggers [1]. Can we have a name describing this aspect? How about:

• BroadcastLogger
• MulticastLogger
• (One)ToManyLogger
• DistributingLogger
• FanOutLogger

---

[1] Since the filtering happens in handle_message(demux::DemuxLogger, ...), it may not be appropriate/obvious to say that a DemuxLogger sends message to all inner loggers. However, if we formalize the API such that the filtering is done by each logger, i.e.,

function maybe_handle_message(logger, args...; kwargs...)
    if comp_handle_message_check(logger, args...; kwargs...)
        handle_message(logger, args...; kwargs...)
    end
end

then DemuxLogger can be implemented as "a logger that sends the message to all child/inner loggers"

function handle_message(demux::DemuxLogger, args...; kwargs...)
    for logger in demux.loggers
        maybe_handle_message(logger, args...; kwargs...)
    end
end

[c42f]

OneToManyLogger and FanOutLogger are pretty jargon free which I like. I think the others may be considered ambiguous or jargony (DistributingLogger - not related to distributed processing; BroadcastLogger - not related to broadcast; MulticastLogger - a bit jargony)

[c42f]

Having said that, we could have MultiLogger if we allow the handle_message to be customized via a closure. This would unify the proposed TeeLogger and SwitchLogger (cf, #23 (comment))

[oxinabox]

MuxLogger is achieved via passing the same child to many parents

See #19