Bonus Points:
- variable(s) for rust-image(s)
- automatically update variables according to the current rust version of the server. If not feasible, use the current rust version of the…
While not a read lock, the Arc Type has this, which seems to be at odds with the whole immutability thing. https://doc.rust-lang.org/std/sync/struct.Arc.html#method.get_mut The docs don't seem to…
While not a read lock, the Arc Type has this, which seems to be at odds with the whole immutability thing. https://doc.rust-lang.org/std/sync/struct.Arc.html#method.get_mut The docs don't seem to…
The error in this case is the inability to report about warnings. This edge-case happens, when there is absolutely no way of informing the sysadmin of other errors, including CLI and E-Mail,…
Seems sensible. It is also probably a good idea to split the config struct into multiple parts.
It is mentioned here, that each level includes the previous ones, but including explicit ordinals is still a good idea.
logging/src/lib.rs:102 will panic if any code requests write-lock on config::CONFIG and then panics. Consider using Arc to ensure immutability and accessibility to the configuration from any thread at any time
logging/src/lib.rs:46 and logging/src/lib.rs:48 will panic if an IO error occurs. Maybe consider to not panic and print another error to the console, informing about the writing problems, rather than crashing the program as logging is not a crucial feature for the program's functioning
I suggest some stability changes:
LogVerbosity doesn't specify values, but logging/src/lib.rs:75 assumes order -> Accidental reordering of the enum would lead to errors
…