-
Notifications
You must be signed in to change notification settings - Fork 55
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
feat: support message ids as strings #82
base: main
Are you sure you want to change the base?
feat: support message ids as strings #82
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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