Conversation
| ) -> Result<()> { | ||
| let (message_id, data, message) = log_message; | ||
|
|
||
| // XXX: seems a lot of effort per-call, we could do this via a wrapper type instead |
There was a problem hiding this comment.
Thoughts? Is this OK or would you prefer a wrapper type? Or both?
I implemented such a wrapper type here: ctrlaltf24@7f0b138 seemed to add more complexity than it's worth.
| .filter(is_us_print_ascii) | ||
| .take(32) |
There was a problem hiding this comment.
We could also validate more of these fields to prevent the user from giving us values that violate the rfc, but at a runtime cost (as I've implemented here) ctrlaltf24@0362d74#diff-c875d3cb38acba1839738726b3d4aa920bec536459b52d5bc5069a91dd1620f5R187-R218 . Not sure if you'd want those changes, assuming no since the additional runtime complexity
MSGID examples in rfc 5424 are strings > For example, a firewall might use the MSGID "TCPIN" for incoming TCP traffic and the MSGID "TCPOUT" for outgoing TCP traffic. - rfc 5424 Unsure how you want to handle validating the message_id's input. The current implementation has the easiest to interact with API boundary, but at the cost of runtime cycles. message id is likely a constant possibly called many times, we could add an option to run the validation once using a wrapper type, then use it safely per call
9e676fb to
568d4e5
Compare
|
FWIW I made a syslog library https://github.com/fast/fasyslog/ that implements similar functionality as well as MSGID as strings. See https://docs.rs/fasyslog/latest/fasyslog/sender/enum.SyslogSender.html#method.send_rfc5424 |
MSGID examples in rfc 5424 are strings
Unsure how you want to handle validating the message_id's input. The current implementation has the easiest to interact with API boundary, but at the cost of runtime cycles.
message id is likely a constant possibly called many times, we could add an option to run the validation once using a wrapper type, then use it safely per call