Joshua MacDonald

I am interested in helping with this specification, but I would like to look to the Prometheus developers for guidance. Let's move to https://github.com/open-telemetry/opentelemetry-specification/issues/1891.

See https://github.com/open-telemetry/opentelemetry-specification/issues/1891#issuecomment-1194348335

IMO filtering is better done in the aggregator, since the cost will be once per export interval instead of once per observation.

~I'm concerned that the `Produce()` method here doesn't know which Reader to produce data for. How would that be handled here? I'm not sure how you'll handle the differences between...

I think it would be good for us, in the future, if we were comparing end-to-end implementations that we could benchmark while having these discussions. Looking at the API above,...

Here is a correctness question: In the API sketched above, it looks like each `View` has no awareness of the other views. The reason I have a single view compiler...

> it is only a true error when creating instruments Yes. I just don't see how the Views will know about the conflicting names. The specification does say what a...

> For that, I would suggest we have the conflicting data in the output stream. That is the specified behavior. I'm asking how the Instrument constructor will show a conflict...

Just so the specification text is included, I am referring to https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/datamodel.md#opentelemetry-protocol-data-model-producer-recommendations ``` 4. Generally, for potential conflicts involving an identifying property (i.e., all properties except `description`), the producer SHOULD...

(See also https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#resolving-duplicate-instrument-registration-conflicts)