The Events API as it is specified currently takes Logs API as a dependency. To generate events one has to obtain a Logger, then create an EventLogger associated with that Logger, then emit events via EventLogger's "Emit" method.

The comment thread here discusses the possibility of further decoupling Events API from the Logger API and having dedicated Events API and Events SDK (where internally Events SDK may share a codebase with Logs SDK).

Essentially instead of the current dependency/data flow of User code -> Event API -> Log API -> Log SDK the proposal is to have User code -> Event API -> Log SDK or User code -> Event API -> Event SDK.

There is a prototype implementation that demonstrates this approach for Java: open-telemetry/opentelemetry-java#5049

The overall structure of Events and Logs API/SDK packages and data flows eventually will look like this:

Open Questions:

• In this new structure of packages it is no longer required to have a separate "Log API" package. Previously it was necessary so that the calls from the Event API via the Logger would end up as "noop" when OpenTelemetry SDK is not present. This is no longer necessary because Events API will have its own "noop" implementation when OpenTelemetry SDK is not present. Given this, should we eliminate the "Log API" package and have Log Library bridges/appenders call directly into Log SDK? If we do this we essentially go back to the original design of the Log SDK (before Events API was added).