Decision: Should we recommend allowing users to set Readers directly?

[dashpole]

Pull exporters (like Prometheus) are expected to use a manual reader under the hood. Users may also want to set the Aggregation of metrics on the reader. In that case, we have two options (discussion. @MadVikingGod and I discussed this offline, and decided to open an issue to discuss further):

1. WithReader option, which allows users to supply their own reader.
2. WithAggregationSelector, which allows configuring the only "safe" part of the reader (since prometheus always wants cumulative temporality metrics).

Similarly, push exporters are expected to use a periodic reader. Push exporters can allow users to configure aspects of the reader (e.g. interval) in one of two ways:

1. Return a metric.Exporter, which can be used with a user-provided/configured metric.Reader.
2. Return a metric.Reader that is preconfigured with temporality, and add WithInterval/WithTimeout/WithAggregation options.

In both push and pull, exporters have to choose between being able to offer safety (by preventing users from setting WithAggregationTemporality) with the cost of the duplicated config surface. In the push case in particular, I suspect setting a correct default temporality is important for exporters which don't want the existing default temporality. This also will have an impact on new options that may be added to metric.Readers over time (e.g. WithBridge, which i'm interested in).

A third option in both cases would be for push/pull exporters to add a more generic WithReaderOptions(Manual/PeriodicReaderOption...), and then override the Aggregation temporality option. There may be more options than that.

[dashpole]

cc @jmacd @MrAlias
This is related to the spec sig discussion on readers vs exporters. These are the challenges/questions I'm having with go's current implementation.

As an exporter, I want:

• To be able to set defaults for reader options, especially temporality.
• To be able to validate user-provided reader options, especially temporality, but also interval/timeout (Google has limits on valid values for those)

As a user, I ideally want:

• To be able to set all options, within the bounds of what the exporter can support.

[MrAlias]

As an exporter, I want:

• To be able to set defaults for reader options, especially temporality.
• To be able to validate user-provided reader options, especially temporality, but also interval/timeout (Google has limits on valid values for those)

As a user, I ideally want:

• To be able to set all options, within the bounds of what the exporter can support.

Yeah, this sounds like what the specification had intended. We should update our implementation to support this.

[MrAlias]

It looks like #3260 and #3341 resolve this issue, closing. Please reopen if this was in error.