Rename Logs API to Logs Bridge API to prevent confusion

[tigrannajaryan]

We keep seeing confusion about what Log API is. There was a proposal [1] to use the term Bridge API to help prevent the confusion.

Please take a look and comment on whether you think this renaming helps and is reasonable.

[1] #3187 (comment)

[yurishkuro]

Not a fan of the name Bridge for this. It conflicts with the use of this term in OpenTracing/OpenCensus Bridge, and it's not immediately apparent what it even means, i.e. it could easily mean the opposite: User -> Bridge -> language logging API.

Why not use the term we already use - Log Exporter API?

[Aneurysm9]

I think this is very analogous to the existing bridges we provide for OpenTracing and OpenCensus, but for logging libraries like log4j or logrus. It provides a way for existing uses of those libraries to integrate with OTel without requiring changes to instrumentation code.

[tigrannajaryan]

Why not use the term we already use - Log Exporter API?

Log Exporter interface is already part of Log SDK. I think naming this document a Log Exporter API would be confusing.

[jkwatson]

big fan!

[tigrannajaryan]

@open-telemetry/specs-logs-approvers please review.

[jmacd]

Have a look at consistent naming with the MetricProducer which is similar.

[jsuereth]

This has enough approvals to merge, but there's concerns around the name bridge.

@tigrannajaryan If you want to entertain the suggestion to use "LogsProducer" like @jmacd suggests, let me know. Will give this another two days to marinate.

[tigrannajaryan]

We have a Log SIG meeting today. I will run the "Producer" suggestion with the SIG. Let's keep this open for 1-2 more days.

[jack-berg]

I prefer bridge to producer - somehow bridge conveys more clearly that this isn't meant to be used by end users. A user might think it's appropriate for them to be a log producer, but less so that they should be writing a log bridge.

I think MetricProducer might benefit from changing to MetricBridge to help avoid users accidentally using the producer / bridge interface instead of async instruments.

[zenmoto]

I think "bridge" makes the intent much clearer.

[tigrannajaryan]

Discussed this in Log SIG today and there was not much support for the name "Producer API". If anyone strongly believes that "Producer API" is a better name for the Logs API please open a PR and link from here.

I will wait for another day to give that alternate a chance to be proposed (and if proposed and we see support for it we can extend the waiting period).

If no alternate PR is created within a day I am going to merge this PR.

@open-telemetry/specs-approvers last chance to object.