Update trace config max defaults

[jtescher]

See the spec change here for details open-telemetry/opentelemetry-specification#942

[morigs]

Do I understand correctly that the task is reduced to replacing these constants with the values of environment variables (with a default value of 1000 of course)?

[jtescher]

@morigs the conventions so far in this workspace have been to have constants (that need to be updated here) and the struct or builder to have a from_env method that would use the env vars

[morigs]

Ok. So default() should always use values of 1000.
But where from_env should be located? Is it ok to be right inside impl Config?
So usage would be Config::default().from_env()?
This will require adding .from_env () to all places where config was created, because environment variables must always be respected (imho).

[jtescher]

@morigs I personally prefer that env vars should always be used when available as well. This project went with the explicit version both because of conventions set by the golang impl (e.g. FromEnv, WithProcessFromEnv, etc) as that is the most widely used distribution, as well as the ambiguity when using struct constructor with defaults.

E.g. Config { max_events_per_span: 100, ..Default::default() } wouldn't pick up the variables.

It does have the somewhat substantial downside that consumers of the API may be confused when they set env vars that do not have the effect they expect. I would be open to re-evaluating the decision to use explicit from env if you want to open an issue for that (e.g. we could make all fields private across the projects to force going through constructors that would pick up the environment)

[morigs]

consumers of the API may be confused when they set env vars that do not have the effect they expect

Totally agreed

if you want to open an issue for that (e.g. we could make all fields private across the projects to force going through constructors that would pick up the environment)

I believe it's better to go this way. But I'm new to the OTel ecosystem and don't know all conventions and best practices. So I rely on your decision

[frigus02]

I'd be happy to move to private fields and automated environment lookup as well.

This would also enable us to add new configuration options without making that a breaking change, I think.