-
Notifications
You must be signed in to change notification settings - Fork 16
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
Make ToDer
trait potentially more convenient by keeping state from to_der_len
for write_der_content
#16
Comments
Hi, You are raising several good points here, on things that took me some time (and headaches) before getting to the current code. And I will humbly admit some better solution could exist :) About ToDer and length computationI hesitated a long time between
[1] Note that the fact that DER length is itself a variable-length fields does not make it easier to compute, and prevents leaving some placeholder bytes that could be updating after the computation. I am not sure I get your idea of the weak normalized form, yet I'm really interested so if there is a way to write a minimal example or just some pseudo code it would be like, I'd gladly have a look. We can also discuss it on IRC/discord if you prefer. Associated types and GAT on traitsI find it funny you are raising that, because it is something I also struggled on for other parts of this crate. In particular, I tried changing the
On that issue, I'd gladly take some advice/hints! Note: for the |
Update: Lines 39 to 158 in c94c739
There is now an Encoder object associated to traits, it might be part of the solution. Maybe a method .prepare() can be added somewhere to populate a stateful Encoder ?
|
This is just a abstract idea I had because I'm currently writing a serializer using this crate:
The pattern I hit right now is that to be able to calculate the final encoded length for
write_der_header
I have to wrap all tagged fields and resolve things like their lengths, recursively.But I have to throw away that state directly afterwards, only to reconstruct it again in the directly following call to
write_der_content
.It's not a big overhead by any means, but I was wondering if I could remove it regardless.
Is that something that'd you be interested in as well and/or would want to work on together?
An idea I had is to make
ToDer
have an associated type that stores what is in essence a weak normalized form. The basic idea is that the WNF can be encoded into bytes directly without conditionals and without having to allocate/wrap any fields.That solution would however make ToDer not object-safe until GATs for trait objects land. Not sure if that is a significant usability problem though.
(Fun fact: The last time I had this issue in asnom I actually inverted encoding, writing out the bodies of fields first and the headers afterwards, making heavy use of scatter/gather-IO. But that approach was absurdly complex, hard to use, and not all that efficient in most cases anyway.)
The text was updated successfully, but these errors were encountered: