-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reverts to dummy response instead of a compile dep on google's empty #64
Conversation
Empty is the only thing that requires a compile dependency on google (not standard proto) types. For example, if you use square wire compiler, you need to add a google library now to compile our proto. Since we haven't really released the service, yet, and empty is binary compatible with an equally empty response, we can change. This reverts to what @ewhauser had originally, which makes things more portable.
zipkin.proto
Outdated
@@ -215,6 +213,10 @@ message ListOfSpans { | |||
repeated Span spans = 1; | |||
} | |||
|
|||
// Response for SpanService/Report RPC. This response currently does not return | |||
// any information beyond indicating that the request has finished. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can consider adding , but may be extended in the future
if the flexibility might help later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds fine to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let’s do this
Empty is the only thing that requires a compile dependency on google
(not standard proto) types. For example, if you use square wire
compiler, you need to add a google library now to compile our proto.
Since we haven't really released the service, yet, and empty is binary
compatible with an equally empty response, we can change.
This reverts to what @ewhauser had originally, which makes things
more portable.