sdk/log: Define in DESIGN.md how Processor and Exporter interfaces can be extended

[pellared]

We should consider creating embedded interfaces as well as no-op implementations for Processor and Exporter. This could make extending these abstractions easier and less frustrating for the users.

This idea came up when I was reviewing open-telemetry/opentelemetry-specification#4030 and open-telemetry/opentelemetry-specification#4024.

Reference: https://pkg.go.dev/go.opentelemetry.io/otel/metric#hdr-API_Implementations

[MrAlias]

SDK interfaces are implemented by end-users, not SDK authors. Extending these interfaces will break them and we should not do that.

[pellared]

Extending these interfaces will break them and we should not do that.

Not if they embed it with a noop implementation.

EDIT: We may also simply add a private() method to the interfaces and add noop implementations that should be embedded.

Side note: I also have a feeling that this proposal is not idiomatic. I think the SDK design doc should describe how we want to extend the SDK if in the specification new methods will be added to the interfaces.

[pellared]

@MrAlias, would you rather prefer adding new interfaces and options that would support them?

[pellared]

We can refer to https://go.dev/blog/module-compatibility#working-with-interfaces and https://github.com/open-telemetry/opentelemetry-go/blob/main/CONTRIBUTING.md#how-to-change-other-interfaces in the DESIGN.md as a way to add new features to Processor and Exporter.