This option was given as a requirement to support configuration-free good defaults for exporting to Prometheus systems, specifically. However, it's been shown that Prometheus' protocol does not actually depend on this, only its client libraries do. Since we have bypassed Prometheus's client libraries for our OTel SDKs, this is no longer necessary.
At the same time, this issue bleeds into other open discussions, for example relating to whether users should be able to specify custom aggregations for an instrument, whether at the point of definition (i.e., while constructing an instrument) or at a separate point (e.g., while configuring a view).
The group is leaning toward support for a Views API and removing the ability for users to specify aggregations and/or aggregation dimensions at the point of definition.
See this comment: #430 (comment)
This option was given as a requirement to support configuration-free good defaults for exporting to Prometheus systems, specifically. However, it's been shown that Prometheus' protocol does not actually depend on this, only its client libraries do. Since we have bypassed Prometheus's client libraries for our OTel SDKs, this is no longer necessary.
At the same time, this issue bleeds into other open discussions, for example relating to whether users should be able to specify custom aggregations for an instrument, whether at the point of definition (i.e., while constructing an instrument) or at a separate point (e.g., while configuring a view).
The group is leaning toward support for a Views API and removing the ability for users to specify aggregations and/or aggregation dimensions at the point of definition.
See this comment: #430 (comment)