I think this would be useful in reference to #17 and #18 as well as to improve maintainability.
PDFRip is basically a big monolithic crate right now, which is fine for smaller software but It will probably not age well as the number of features (and therefore probably the number of dependencies we have) increase, potentially causing issues regarding different versions of crate dependencies being incompatible.
Additionally splitting it into multiple crates allows us to enforce a stricter dependency chain between our different parts.
E.g. We can ensure Clap (argument parsing) is only accessible from our main crate, guaranteeing engine.rs is unable to somehow depend on it.
I propose to split PDFRip into the following crates with the following responsibilities:
Main binary - Essentially becoming a presentation layer responsible for interactions with the user. i.e. Argument parsing and/or Api related things as well as selecting a logging frontend and, if possible with the proposed dependencies, the progressbar.
Engine crate, responsible for the business logic of cracking passwords. It should depend on our Producer and Cracker crates.
Producer crate. Defines the "Producer" trait and contains the different cracking methods, i.e. "custom-query", "default-query" and such.
Cracker crate, implements the PDFCracker struct. Allowing us to decouple the rest of the crate from depending on the PDF crate we're currently using for our decryption logic.
We can probably do all this inside this one repository by utilizing Cargo's workspace feature
The proposed structure can be represented in the following way:
I think this would be useful in reference to #17 and #18 as well as to improve maintainability.
PDFRip is basically a big monolithic crate right now, which is fine for smaller software but It will probably not age well as the number of features (and therefore probably the number of dependencies we have) increase, potentially causing issues regarding different versions of crate dependencies being incompatible.
Additionally splitting it into multiple crates allows us to enforce a stricter dependency chain between our different parts.
E.g. We can ensure Clap (argument parsing) is only accessible from our main crate, guaranteeing engine.rs is unable to somehow depend on it.
I propose to split PDFRip into the following crates with the following responsibilities:
We can probably do all this inside this one repository by utilizing Cargo's workspace feature
The proposed structure can be represented in the following way:
The image was generated using https://structurizr.com/dsl with the code from the attached file. structurizr.txt