Make sure the current Logs Bridge API/SDK design doesn’t prevent future addition of end-user facing log API

[tigrannajaryan]

This was raised by @bogdandrutu during presentation of the Logs Bridge API/SDK in spec SIG.

We may need to show what a hypothetical end-user facing log API may look like and that it is doable as an addition to the Bridge API.

[tigrannajaryan]

cc @open-telemetry/specs-logs-approvers

[jack-berg]

Its a good question. In java, we publish all our APIs in a single artifact called opentelemetry-api. Within this there are different packages (a java specific organization construct) for each signal (e.g. io.opentelemetry.api.trace, io.opentelemetry.api.metrics, etc).

Although we call it the "Logs Bridge API", I was thinking that the code would land in the standard opentelemetry-api artifact, under the io.opentelemetry.api.logs package. I figured we would call it the Log Bridge API in documentation (opentelemetry.io, javadoc, etc), but don't need to reflect that name in the package. I.e. DON'T call the package something like io.opentelemetry.api.logbridge.

This would allow us to rebrand and expand the scope to be user facing, in the event of a future end-user facing log API. The current shape of the Log Bridge API lends itself well to becoming user facing some day, but would need some (backwards compatible) additions like the ability to query for the enabled log level.

I want to reiterate that while I think our strategy would allow us to expand the scope to be user facing, there's a strong consensus in the java SIG that we do not want to create yet another logging API, and would push back on any future spec movement to do so.

[tigrannajaryan]

@jack-berg that's my feeling as well. Keep package name generic. Later we can add methods to Logger (e.g. error() or debug()).

I don't know if we need to show more details of what a potential extended API can look like.

[tigrannajaryan]

@open-telemetry/specs-logs-approvers any thoughts on this?