Encoder without EOF about client_rust

[amunra]

I'm happy to raise a PR, but if I am wondering if you'd have a better suggestion, especially in the context of these upcoming changes: #149.

[mxinden]

I like that the client doesn't do HTTP serving and stick to the protocol, so it's 99% of what I need.

Good to hear.

What causes me trouble is just a single line of code:

    writer.write_str("# EOF\n")?;

:D

Would you consider a variant of the encode function that doesn't write out the # EOF?

Generally yes. I see the use-case of wanting to combine multiple encode outputs, whether from the same client library or different ones.

That said, in case performance is not an issue for you and you are fine with a small hack, why not encode into a String and then drop the last line?

[mxinden]

I'm happy to raise a PR, but if I am wondering if you'd have a better suggestion, especially in the context of these upcoming changes: #149.

I don't see how #149 would help or effect your situation. You could implement your own Collector that collects the metrics from the parts written in a different language. Though that sounds very painful.

[amunra]

Ours is a performance-sensitive application and I'd rather not have to double-buffer :-)

We embed Rust, rather than the other way around.

[amunra]

The reason why I was mentioning PR #149 is that as I was looking at it I noticed the new encode is implemented as:

/// Encode the metrics registered with the provided [`Registry`] into the
/// provided [`Write`]r using the OpenMetrics text format.
pub fn encode<W>(writer: &mut W, registry: &Registry) -> Result<(), std::fmt::Error>
where
    W: Write,
{
    registry.encode(&mut DescriptorEncoder::new(writer).into())?;
    writer.write_str("# EOF\n")?;
    Ok(())
}

pub(crate) struct DescriptorEncoder<'a> {
    writer: &'a mut dyn Write,
    prefix: Option<&'a Prefix>,
    labels: &'a [(Cow<'static, str>, Cow<'static, str>)],
}

The alternative here might be to expose the DescriptorEncoder as pub rather than pub(crate). I think an independent function is cleaner (though I can't necessarily think of a good name).

If not, I'll wait for PR #149 to be merged and raise mine after (given that code is changing anyways).