tracing

tracing copied to clipboard

This is a rough draft of an API for passing timestamps into any formatter, rather than just ones that use fmt::Format. I haven't done all of the plumbing for this change yet, just sketched out the APIs.

It's not clear if we can do this without a breaking change, unfortunately, since the with_timer method changes a type parameter of fmt::Format. We would want to change with_timer to not require that the event formatter be fmt::Format...but if we did that, we would no longer be able to change its type parameter.

One non-breaking option is to leave that system in place but deprecate it in favor of a new API that works with any event formatter, but then we would have to come up with a better name...

This is a pretty helpful change, thanks. Upon working more with tracing-glog, would it be a good idea to expose some of the simpler bits of configuration (e.g., thread names, files, targets) available on Format to the subscriber as a FmtCfg struct, or should I should just bite the bullet and make tracing-glog a layer instead of a formatter atop of fmt?

(I suppose this impacts the logfmt formatter you were playing around with as well.)

Upon working more with tracing-glog, would it be a good idea to expose some of the simpler bits of configuration (e.g., thread names, files, targets) available on Format to the subscriber as a FmtCfg struct, or should I should just bite the bullet and make tracing-glog a layer instead of a formatter atop of fmt?

unfortunately, with the way that struct currently works, this is a bit annoying because the Format struct wraps a marker type that determines what formatting is used, rather than belonging to a formatter type. This means it can't easily be used in external crates, because an impl Format<MyType> is an implementation for a foreign type.

i think we might want to redesign this part of the formatter system so that a config struct can be passed in to formatters from other crates, instead, but that seems like a separate change...