> Huh. I thought we were trying to make mirclient independent of mircommon? This > ties them together more.
I don't recognise that aspiration. Nor do I think it feasible.
> As it stands, this is really only going to be useful in tests, right?
Yes.
> I rather > thought you might take this opportunity to add a client-facing mirclient log > API (which we need at some point).
Providing a C style API for customizing the logging is a significantly bigger change than this simplification.
> This doesn't seem wrong, though. Unless we haven't given up on making > mirclient not depend on mircommon?
It could be wrong, if we decide that this mechanism for customizing logging should be deprecated. (See discussion in linked the bug.)
« Back to merge proposal
> Huh. I thought we were trying to make mirclient independent of mircommon? This
> ties them together more.
I don't recognise that aspiration. Nor do I think it feasible.
> As it stands, this is really only going to be useful in tests, right?
Yes.
> I rather
> thought you might take this opportunity to add a client-facing mirclient log
> API (which we need at some point).
Providing a C style API for customizing the logging is a significantly bigger change than this simplification.
> This doesn't seem wrong, though. Unless we haven't given up on making
> mirclient not depend on mircommon?
It could be wrong, if we decide that this mechanism for customizing logging should be deprecated. (See discussion in linked the bug.)