Skip to content
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

Support Protocol Buffer Message Decoding #21

Merged
merged 2 commits into from
Jun 27, 2013

Conversation

matttproud
Copy link
Member

The next API will support Protocol Buffer telemetry streams in addition to the standard JSON. This will enable more rapid development of additional clients while the simple text and JSON formats are added.

This commit introduces an incomplete processor that decodes varint
record length-delimited streams of io.prometheus.client.MetricFamily
Protocol Buffer messages.  The Go client presently does not support
generation of said messages, but this will unblock a number of Java
changes.
This commit introduces protocol buffer telemetric stream decoding.
@ghost ghost assigned juliusv Jun 26, 2013
@matttproud
Copy link
Member Author

/CC: @bernerdschaefer

}
switch mediatype {
case "application/vnd.google.protobuf":
// BUG(matt): Version?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, should the version conceptually be a subhierarchy of the media type? E.g. with protobuf version, we start at a separate 0.0.1 again, but use the same header to indicate it?

@juliusv
Copy link
Member

juliusv commented Jun 26, 2013

👍 in general, but we should reach some consensus about object creation styles. IMO unless there's a good reason for new vs &...{}, I'd prefer keeping the latter.

@bernerdschaefer
Copy link
Contributor

I don't have the exact details on hand, but a grep through the stdlib showed new(foo) to occur much more frequently than &foo{} (I believe 8 times more so).

Bernerd

On Jun 26, 2013, at 19:39, juliusv [email protected] wrote:

in general, but we should reach some consensus about object creation styles. IMO unless there's a good reason for new vs &...{}, I'd prefer keeping the latter.


Reply to this email directly or view it on GitHub.

@matttproud
Copy link
Member Author

@bernerdschaefer I am betting, too, that you see this far more frequently for struct {}s that follow the pattern of default initialization versus

o := new(O)
o.ImportantState = initializedValue

Staying idiomatic is important to me, even if there are consistency issues. As long as components are small, inconsistencies can be quickly remedied.

matttproud added a commit that referenced this pull request Jun 27, 2013
…nation

Support Protocol Buffer Message Decoding
@matttproud matttproud merged commit 1fb7c8d into master Jun 27, 2013
@matttproud matttproud deleted the feature/accept-header-discrimination branch June 27, 2013 09:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants