Review component public API

[codeboten]

Before considering component 1.0, we need to review the public API to ensure what is exposed makes sense https://pkg.go.dev/go.opentelemetry.io/collector/component

[codeboten]

Some thoughts:

• should BuildInfo be in this package? since its more directly tied to the service running, it might make more sense to move it to that package
• TelemetrySettings should be moved into the telemetry package

[bogdandrutu]

should BuildInfo be in this package? since its more directly tied to the service running, it might make more sense to move it to that package

I think cannot be moved to the "service" since you need to pass this to components, so will create a circular dependency.

TelemetrySettings should be moved into the telemetry package

Same issue about dependency.

[bogdandrutu]

Before considering component 1.0, we need to review the public API to ensure what is exposed makes sense https://pkg.go.dev/go.opentelemetry.io/collector/component

@codeboten we also need to make sure that "consumer" package is 1.0 before :)

[mx-psi]

IMO BuildInfo does not make sense in service: the components should not know anything about the service other than through the component.Host interface; ideally we should be able to completely replace service with a new implementation without changing anything about the components.

For TelemetrySettings, I think it makes sense to move it to telemetry, but my proposal would be to make telemetry into a separate module outside of service. I want to work on this at some point, but haven't gotten around to it lately.

[mx-psi]

I am wondering if we should split component into further packages. For example, we could have componentstatus and componentfactory as separate packages. It currently feels like a mish-mash of important but unrelated things

[TylerHelmuth]

Did a review of Component's public API and here are my thoughts:

1. We could rename/refactor DataType (see Does DataType belong to component? Can we make it a type itself? #9429). Let's keep discussion on that specific field in that issue.

2. We could move component.Telemetry to its own package as component.Telemetry is not used anywhere without component. But I struggle to find end-user value in such a change at this point.

3. We could move component.BuildInfo to its own package as component.BuildInfo is not used anywhere without component. But I struggle to find end-user value in such a change at this point.

4. The component.Factory has a comment that claims:

   // This interface cannot be directly implemented. Implementations must
   // use the factory helpers for the appropriate component type.
   

   but the interface itself doesn't include anything that prevents something from implementing the interface. Do we need to make it sealed? We'd have to do a bit of refactoring to seal the interface to make the implementations in receiver/exporter/processor work.

[mx-psi]

For (2) and (3) I feel like, unless not doing it would delay component 1.0, we should keep them where they are.

I said before

For TelemetrySettings, I think it makes sense to move it to telemetry

If memory serves this was because I though different telemetry implementations could have different telemetry settings, but I don't think that should be the case: the interfaces would stay the same.

[mx-psi]

@TylerHelmuth Should we close this as completed since we have a different issue for (1)?

[TylerHelmuth]

I agree, there is not appetite for 2. and 3.