feat: allow encoding data without owning the it #38
Conversation
There was a problem hiding this comment.
After looking through this, I think it might be simpler just to introduce a couple of functions like encode_parts(tag: &str, contents: &[u8]) -> String and encode_parts_config(tag: &str, contents: &[u8], config: EncodeConfig) -> String and allow the user to just pass the pieces to those, leaving the existing functions as just a wrapper that extracts the tag and contents by reference from the Pem struct and passes them along.
| use parser::{parse_captures, parse_captures_iter, Captures}; | ||
| use std::borrow::Borrow; |
There was a problem hiding this comment.
cargo build and cargo test throw unused import warnings about this.
| contents: &[1, 2, 3, 4], | ||
| }; | ||
|
|
||
| let encoded = encode_ref(pem.clone()); |
There was a problem hiding this comment.
encode_ref does not exist (and shouldn't given the approach of making this be transparent to the user) so I think you meant encode here.
| /// use pem::{RefPem, encode}; | ||
| /// | ||
| /// let pem = RefPem { | ||
| /// tag: "FOO", | ||
| /// contents: &[1, 2, 3, 4], | ||
| /// }; | ||
| /// encode(&pem); |
There was a problem hiding this comment.
This example fails because you don't have an Into<RefPem<'p>> implementation for a &RefPem<'p> itself. So does the other example you added for the encode_config function. That said, I am not sure that having an implementation to go from a &RefPem to a RefPem makes a whole lot of sense and it is going to be weird that one of the ways you call it is encode(&pem) and the other way is encode(ref_pem).
Sure this would work as well. Do you want me to change the PR? |
Yeah. Otherwise, I won't have a chance to do it for a bit. |
My use case is to encode existing data into the PEM format.
However, with the current API, I need to own the data, and so I do need to copy the arrays, just for encoding it. Which also doesn't seem to consume the data.
I added a new struct
RefPem, which is intended to holdPemdata, just by reference. And modify the existing encode functions (not yet the "many" variants) to support using anything which canInto<RefPem>, which is implemented for&Pemtoo. So the API for the user shouldn't be different.