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
Consider merging the functionality from crate "binary_macros" #7
Comments
The functionality of +1 on merging. |
Hi, I am currently trying to finish v2. When it's done I could consider this for v2.1. In the meantime, just so that I understand better what it is about, could you provide me with examples and links to how and when this feature would be useful? My current understanding is that it permits to decode encoded strings from files, environnement variables, or constant strings at compile time. At first glance this looks outside the scope of data-encoding in the sense that reading files or environnement variables is something orthogonal to the purpose of data-encoding. The compile-time aspect could be considered, but there are already solutions like lazy_static (which is not really compile-time), build.rs, and hard-coded literals. I would prefer to make those tools easier to use, rather than bake their use in data-encoding. I am actually currently facing such decisions for v2.0.0-rc.2 to allow users to define custom encodings as global variables, with either lazy_static, build.rs, or hard-coded literals (with const fn). |
Thanks for asking! First of all, my motivation for the crate was that I wanted to bundle a compile-time pepper (in addition to the normal salt) for hashing passwords. It has also other uses, but the main ones I've come up with are bundling crypto stuff like keys, secrets and certs at compile time, while having the file as a nice base64 or hex format, instead of a binary. Because I'm bundling the data at compile time, a macro is necessary. Of course, there exists macros for bundling binary data at compile time, but if you also want to decode encoded data, it's better to do the decoding at compile time too. The reason is simple: in the case your data is borked, you get the error messages earlier (during compilation, not after deployment) and you get the assurance that at least that part of the app is fine. So, one could bundle the raw data using the macros from the std, but they would still be in an ASCII format. Using this library as a macro is necessary if you want to end up with a binary with the ASCII already decoded into the final binary data. |
Hi Pyry, I created #15 which adds a data-encoding-macro crate with the following macros:
The main differences that I can see with
If you have some time, I could use your input before submitting. Here are the two files that describe how to use those macros:
I'll probably submit this week-end and do further modifications if needed. Thanks, |
I ended up closing the differences with the
|
Hi, I'm the author of crate
binary_macros
: https://github.com/golddranks/binary_macrosIt's a simple wrapper around the conversions implemented in this crate. The use-case is to enable using hexadecimal, base64 etc. in settings files and environment variables that are compiled statically in. I think there would be some value in merging the macros to this crate, since I think the discoverability of binary_macros is low. What do you think?
The text was updated successfully, but these errors were encountered: