You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Used the library today, but I had to go through some difficulties to get it working.
To make it easier to use correctly, I suggest to remove the non raw structs.
Structs like PublicKey have a Base64 field for the user and a Raw field for the actual library. This has multiple disadvantages:
Redundant information: The user may change the Base64 part later, which won't automatically update the Raw part and could cause weird behaviour (like GetSigFile() using the new signature value, while in the background the old one is used by the rest of the code)
The user has to first create the type and then assign the Base64 value to make it usable
Functions need to check, if the Raw part is filled and call decode (which is btw. currently bugged)
I would suggest replacing them with the raw counterparts and having a function to create the struct from a Base64 value (ParsePublicKey or similar).
This change will also eliminate the need for the NewXXX calls to create instances of structs. And the Decode and Encode functions will be embedded in the actual parsing and generation of the textual versions.
I know that this is basically a big API break and before wasting effort creating a PR, I want to know, if this has a chance to be merged.
The text was updated successfully, but these errors were encountered:
Used the library today, but I had to go through some difficulties to get it working.
To make it easier to use correctly, I suggest to remove the non raw structs.
Structs like
PublicKey
have aBase64
field for the user and aRaw
field for the actual library. This has multiple disadvantages:GetSigFile()
using the new signature value, while in the background the old one is used by the rest of the code)Base64
value to make it usableRaw
part is filled and call decode (which is btw. currently bugged)I would suggest replacing them with the raw counterparts and having a function to create the struct from a Base64 value (
ParsePublicKey
or similar).This change will also eliminate the need for the
NewXXX
calls to create instances of structs. And the Decode and Encode functions will be embedded in the actual parsing and generation of the textual versions.I know that this is basically a big API break and before wasting effort creating a PR, I want to know, if this has a chance to be merged.
The text was updated successfully, but these errors were encountered: