Rename Log API to Log SPI to prevent confusion #3187
Conversation
We keep seeing confusion about what Log API is. There was a proposal [1] to use the term SPI (Service Provider Interface) to help prevent the confusion. Please take a look and comment on whether you think this renaming helps and is reasonable. [1] open-telemetry#2911 (comment)
tigrannajaryan
force-pushed
the
feature/tigran/renamelogspi
branch
from
85b2689 to
b349bba
Compare
|
This should be only merged if we see lots of approvals. |
| @@ -1,4 +1,4 @@ | |||
| # Logs API Interface | |||
| # Logs SPI Interface | |||
There was a problem hiding this comment.
| # Logs SPI Interface | |
| # Logs SPI (Service Provider Interface) |
|
I don't think service provider interface (SPI) is the correct "name" for this rename... As this seems to be a Java centric term that is not generally used. The thing that irks me in the "Service" portion of this name...
|
There was a problem hiding this comment.
This appears to mostly be a cosmetic change to help further draw people's attention to the fact that this is not an end-user facing API like the trace and metric API. In other words, it seems this new naming will have no affect on implementations.
I'm open to other names, but SPI seems ok.
"Log Appender API" seems too restrictive since the important aspect of this API is that it provides a shim between OpenTelemetry and some other software component - log appenders being perhaps only one type of component.
Log Shim API? ... SAPI 😆 kidding..
adapter/appender/shim/bridge/interop 🤷♂️ |
|
I'd prefer "Log Bridge API". The goal of this PR to more clearly convey that this is not an API for end users. I don't think "SPI" accomplishes this. In fact, I'm not sure what I come away thinking when I read "Log SPI". From a java perspective, SPI is a sort of pluggable interface which can be provided by the app or third party to change the behavior of a library / framework. The appenders we've written sort of function like this, but don't actually use the Java SPI mechanism. If "SPI" is a java-centric term, but the java log appenders don't function as SPI implementations, then I'm not sure what we're conveying with this name. Additionally, "API" is a well established term in OpenTelemetry. By introducing a new term like "SPI" we need to be able to define how SPIs are similar / different from an API. Do we expect additional SPIs in the future? Under what conditions do we call something an SPI? In contrast, "Log Bridge API" keeps the existing "API" vocabulary, while clearly and succinctly conveying its purpose, as it's unlikely a user who comes across something called "bridge API" would think that they're supposed to use it. I don't mind other terms like "adapter", "appender", "shim", but prefer "bridge" as its the most clear IMO and is quite succinct. Additionally, we use the term "bridge" similarly in other places in the specification. |
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] 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] open-telemetry#3187 (comment)
|
I like "Bridge API" more than "SPI" too. It reflects the intent more directly. Here is a PR with that version: #3197 |
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] open-telemetry#3187 (comment)
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 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)
|
Closing this in favour of #3197 which received much wider support. |
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] #3187 (comment)
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/opentelemetry-specification#3187 (comment)
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/opentelemetry-specification#3187 (comment)
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/opentelemetry-specification#3187 (comment)
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/opentelemetry-specification#3187 (comment)
We keep seeing confusion about what Log API is. There was a proposal [1]
to use the term SPI (Service Provider Interface) to help prevent the
confusion.
Please take a look and comment on whether you think this renaming helps
and is reasonable.
[1] #2911 (comment)