Skip to content
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

Improve API robustness and remove public dependencies #21

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

MattesWhite
Copy link

Hi,
thanks for implementing this parser crate. It helps a lot. However, while including the crate in my business logic a found some unergonomic API designs that this PR tries to solve.

The main problem I found is that there are types of the crate's dependencies in the crate's public API. Namely, types from asn1-rs and nom. This required me to also depend on these crate to handle OIDs and to handle nom parser errors. But this gets problematic when versions between snmp-parser, asn1-rs and nom start to differ. Actually, there is already a difference between nom v7.0 used in snmp-parser and the current nom version v7.1.

This PR removes those public dependencies via re-export or returning std types instead. Feel free to cherry pick single commits. I'm also open to discuss alternative solutions.

The #[from] attribute of thiserror also implements the Error::source() method
which allows better error reporting compared to a custom From implementation.
With this re-export users of snmp-parser no longer need to also depend on
asn1-rs. This prevents some nasty probelms when the asn1-rs version used
in this crate and the version used by the user differ, making the crate's
API more robust overall.
Using nom::internal::IResult in the crate's public API required users to depend
on nom as well for error handling. This dependency is removed by returning the
std Result in the public API. For now the 'nom parser functions' are preserved
as the internal_ functions so we can make them public again if required.
@MattesWhite
Copy link
Author

@chifflier Any opinions on this PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant