Pablo Baeyens

Should we also create `nopprocessor` instead of https://pkg.go.dev/go.opentelemetry.io/collector/[email protected]/processortest#NewNopFactory?

I believe @evan-bradley worked on this primarily for OpAMP, the processor would not be useful for that use case but consistency is a relevant issue

@bogdandrutu I feel like this should stay in `component.Host`: this feels like *the* essential functionality a `component.Host` must have in order to support basic use cases like authentication, encoding or...

@jpkrohling This would still be available, just as an optional interface. Right now: ```go var host component.Host = getComponentHostSomehow() doSomethingWithExtensions(host.GetExtensions()) ``` After the change proposed by @bogdandrutu we would have...

> We are adding the notion of "extension" within the component package which should be agnostic of different component types (ideally). @bogdandrutu `component` is not agnostic to component types: we...

> > component is not agnostic to component types: we define [component.Kind](https://pkg.go.dev/go.opentelemetry.io/collector/component#Kind). > > I think now component type can be in service? Moving `component.Kind` to `service.Kind` introduces a couple...

We discussed this on the 2025-01-27 stability meeting. Some thoughts: - It doesn't seem like having a top-level package would make sense - The two things Bogdan wants to look...

> * `component.Component` shouldn't be equal to `extension.Extension`, it should be the same as in `receiver.Logs` (embedded). I believe this can be done, see #12208

> If we leave component.Kind where it is, look into whether adding new component kinds without modifying component would be feasible For this point: this is doable today, since a...

I am closing this as completed with the merge of #12214