Description
Feature Request
Maybe more of an idea than a feature request…
Instead of stack of layers with registry on the bottom, use a tree with registry in the root.
Crates
Possibly to tracing-subscriber.
Motivation
The motivation is two-fold.
First, I find the model where the Registry that enriches data sits on the bottom of a linear stack hard to grasp, as the information travels bidirectionally.
Second, when trying to implement both some metric extraction and logging at the same time, I find it hard to compose them together. The new proposals, like #508, that seems to address the immediate concern, but it seems to lose some part of flexibility and has two kinds of filters. What I have in mind works uniformly and can filter arbitrary sub-tree of the subscribers.
Proposal
A subscriber seems to be doing two things:
- Assigning IDs and keeping track of things.
- Processing events and spans and exporting that data outside of the application in some way.
It seems it's possible to use the Registry for the first and then implement a Layer for the second.
What I'm thinking about is putting the registry at a top of all the thing. It would assign IDs, provide context, etc. Then it would call into a consumer (I probably don't want to call it a layer). The consumer would then be able to either process it, or filter it and call another consumer. Or, it could contain multiple parallel consumers that are independent on each other, allowing a kind of branching.
That way, one could combine branching & filtering in arbitrary way to have multiple log destinations, metrics, etc, without influencing each other, but also placing a filter directly below the registry to disable it for the whole tree.
Information would be flowing only from registry to the leaves of the tree, with the exception of the register_callsite that would be aggregated from bottom to the top (and would allow the registry to disable processing in itself too, as needed).
I also wonder if it would be possible to create an adapter that would somehow wrap a full-featured subscriber into a leaf of this tree in some way (with mapping of IDs, probably).
I wonder if this has been considered and turned down for some reason, or if it would be worth trying out. I'm willing to draft some code and then show it to discuss if it makes sense to integrate (either as part/replacement of tracing-subscriber, or something else).