The new vendoring was produced by running:
godep save -r ./examples/... ./prometheus/... ./text/... ./model/... ./extraction/...
Two things to note:
- "extraction/processor0_0_{1,2}_test.go" imported a package from
"github.com/prometheus/prometheus", all for just one tiny testing
function. To not have to deal with a circular vendoring dependency, I
simply replaced the usage of the function by some in-line logic.
- godep grouped the rewritten imports slightly differently for some
reason, but at least the standard library imports are still in a
separate section. Not sure if it's worth manually keeping our old
import grouping scheme or if we should simply use that godep-generated
one.
Most important here is the simple & flat text format, but while I'm on
it, I have also added the text representations for protobufs (which is
purely meant for debugging purposes). I hope my basic idea about
handling those various protocols (and the text package) becomes
clearer now.
Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
The idea here is to always go via the protobufs if dealing with the
text format. That won't always be the most efficient way, but it
avoids the multiplicity of conversion routines required for direct
conversion (e.g. text format -> internal representation in the
Prometheus server). The loss of efficiency is acceptable because the
text format should not be used in high performance (high throughput,
low latency) situations anyway.
In that way, the text format stays perfectly isolated from other parts
of the code. To receive text format, just plug the conversion in
before the code path that normally reads protobufs. Correspondingly,
for sending text format, simply replace the WriteDelimited call by a
text.Create call.
Nevertheless, the conversion code itself is optimized for efficiency
and minimized memory churn (which was one of the reason for handcoding
the parser and not using a lexer/parser code generation tool).
Change-Id: Iee45ffe8aa421a844225d13a1f859becd8a3b066
Julius Volz