Rename Logs API to Logs Bridge API to prevent confusion #3197
Conversation
tigrannajaryan
force-pushed
the
feature/tigran/logbridgeapi
branch
from
6393a53
to
0400ee0
Compare
tigrannajaryan
force-pushed
the
feature/tigran/logbridgeapi
branch
from
0400ee0
to
d30c66c
Compare
tigrannajaryan
changed the title
|
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? |
|
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. |
Log Exporter interface is already part of Log SDK. I think naming this document a Log Exporter API would be confusing. |
|
big fan! |
|
@open-telemetry/specs-logs-approvers please review. |
arminru
added
spec:logs
tigrannajaryan
force-pushed
the
feature/tigran/logbridgeapi
branch
from
d30c66c
to
0503ab6
Compare
We keep seeing confusion about what Logs 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] open-telemetry#3187 (comment)
tigrannajaryan
force-pushed
the
feature/tigran/logbridgeapi
branch
from
0503ab6
to
bba4419
Compare
|
Have a look at consistent naming with the MetricProducer which is similar. |
|
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. |
|
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. |
|
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. |
|
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. |
…ry#3197) We keep seeing confusion about what Logs 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] open-telemetry#3187 (comment)
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)