Replies: 1 comment 4 replies
-
The custom TOML parser builds a key/value hashmap which allows to easily parse rules and other configuration settings. All TOML parsers I checked did not have this option.
In the case of JMAP, it was for performance and because
A simple OAuth token was needed and PASETO is a bit too bloated for what Stalwart needs No custom crypto is being done though, tokens use AES256_GCM_SIV along with BLAKE3. |
Beta Was this translation helpful? Give feedback.
-
I've been skimming through the codebase while configuring this to figure out what were the default config values, and noticed that there's a custom toml parser implementation, is there any reason to do that instead of defining some structs with derived
serde::Deserialize
and parse the config using thetoml
crate?Same for the JMAP parser, I'm not sure why not just use
serde
and something likeserde::Value::pointer
+serde::Value
for the JMAP result references.These parsers make it much harder to understand the codebase, though in the case of JMAP I can somewhat understand it, if there's a performance benefit to doing it this way.
Another thing are the OAuth tokens, why not just use PASETO? It's generally better to not make custom crypto. Token revocation is a bit complicated though, but if you plan to do individual token revocation, that likely would involve storing information about the tokens in the database, at which point you might aswell just use a randomly generated string stored in the database.
EDIT: right, also the current situation with the config is a bit weird, there often aren't any clear defaults when I tried removing the column mappings thing, I assumed that it would just default to the values in the example, but that wasn't the case apparently. All of these config options would be much easier to keep track of if they were a struct instead of using toml,get("path.to.property") everywhere and unwrapping it with the default value.
Beta Was this translation helpful? Give feedback.
All reactions