Description
The event API and SDK have been removed from the spec in favor of extending the log API / SDK with those concepts.
There's also an open PR which would remove the emit event operation from the log API. As shared by @trask in the 1/9 java SIG, other prototype language implementers of events don't see enough value in having separate API and want to roll the functionality into the existing emit log record operation. From opentelemetry-java's perspective, our implementation of emit log record was not designed to be user facing, and is too easy to do the wrong thing from an events standpoint (i.e. accidentally omitting the very critical event name parameter). I am opposed to labeling our emit log record operation as the canonical way to emit events. There's an issue to potentially bring back a dedicated emit event operation later.
This domain is obviously still evolving, but we need to answer the question of what we do with our event API / SDK surface area in the interim. Some options:
- Delete the event API / SDK without a current replacement. Tell anyone that has been prototyping with it to move to emit log record, indicating that this is an interim solution.
- Delete the event API / SDK and add an equivalent user facing / ergonomic to ExtendedLogger in
opentelemetry-api-incubator
. Essentially, we exercise our ability to have un-specified syntactic sugar APIs, and classify this new emit event operation as syntactic sugar. - Keep event API / SDK around until the spec gives us a user facing event API.