I was running through the propagators, and I think it would be worth considering renaming "Resources" to "StaticContext".
Motivation:
-
Resources effectively are a set of labels that are static for the lifetime of the application. As there is currently no way to represent other values that are static for the lifetime of the application, people will add Resources that have nothing to do with the underlying 'resource' (e.g, environment or version).
-
When one is constructing a set of labels to attach to some piece of telemetry (logs, traces, etc), they will be extracted from the various "Context" objects. by calling this StaticContext, it immediately signals to consumers of labels that this is another pool of values they can retrieve context from. i.e. you could switch from:
-
you can pull telemetry tags from SpanContext, DistributedContext, and Resources
to:
-
you can pull telemetry tags from any of the contexts: SpanContext, DistributedContext, and StaticContext.
I was running through the propagators, and I think it would be worth considering renaming "Resources" to "StaticContext".
Motivation:
Resources effectively are a set of labels that are static for the lifetime of the application. As there is currently no way to represent other values that are static for the lifetime of the application, people will add Resources that have nothing to do with the underlying 'resource' (e.g, environment or version).
When one is constructing a set of labels to attach to some piece of telemetry (logs, traces, etc), they will be extracted from the various "Context" objects. by calling this StaticContext, it immediately signals to consumers of labels that this is another pool of values they can retrieve context from. i.e. you could switch from:
you can pull telemetry tags from SpanContext, DistributedContext, and Resources
to:
you can pull telemetry tags from any of the contexts: SpanContext, DistributedContext, and StaticContext.