Hello, I saw your message about issue #18 on Hacktoberfest's Discord. I have tried to address it, I have set tokio as a non optional dependency.

Using this feeds.txt:

https://antoniosbarotsis.github.io/index.xml
https://blog.rust-lang.org/feed.xml
https://blog.rust-lang.org/inside-rust/feed.xml
https://github.blog/feed

This is the output of hyperfine:

• With the synchronous requests:

• New asynchronous requests:

Please feel free to correct anything, this is my first time working with async and tokio in rust.

It would be helpful if you posted your feeds.txt, so i could test it more thoroughly. Thanks.

closes #8

details

Implemented a benchmark for the map_to_html function, to do it, i moved the content from src/util.rs to src/lib.rs (see library crate)

I also tried to add a benchmark the download_blogs function, but the 100 iterations would take a lot of time:

Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 1603.1s, or reduce sample count to 10.
Benchmarking map to html: Collecting 100 samples in estimated 1603.1 s (100 iterations)

I can reduce the iterations or try to figure out another solution, what do you think fits better?

Greetings! Found your great project in Hacktoberfest discord: sorry for not contacting you first, I wanted to assemble a working example before proposing.

I'll be glad if you could evaluate this implementation proposal, including the followings:

• Implementation for running a local mail command, in case you're running the project where postfix or mailutils is configured

Small refactors

• Error/default handling for DAYS env variable.
• EmailProviders has a tested path and should permit easier implementation of new backends

Breaking changes

• Trait function EmailProvider::send_email() no longer requires api_key parameter
• EmailProviders is now implemented with TryFrom, since Provider setup might fail for missing configurations.

Possible future improvements

• Having a better parameterized interface as command line, using clap
• Fail MailCommand creation when there is not an actual mail command available
• Support other mail-providers at commandline ( sendmail, mutt, etc. )

I'll be glad to hear your feedback, also I understand this might take a path that wasn't intended in the original design. Thanks you very much for your work.

There are currently no tests present in the project. While it is very easy to test manually, automated tests are definitely quite handy.

I'm interested in testing that downloading and parsing (separately) RSS feeds are working properly. There should be a way to define a list of feeds to be used in these tests.

Feel free to make any additional tests!

Adding automated code coverage reports would also be a very much welcome addition.

Currently, the feeds are being read from a local text file here. This is a rather bad design choice as you might want to add new feeds quite often. It is especially annoying if you have deployed this as a docker image since you need to rebuild it (even though that is fast because of caching).

A new function should be created that first attempts to read the feeds from an environment variable. If that is not found or is empty, it should try to read from the file as it is doing now.

The format of the env variable contents is up for discussion but I feel like a line of semicolon-delimited links would suffice (so [link];[other link].

This writes one basic test for get_page, using a valid URL. In addition, to add some security because the reader expects XML, I added some validition on the content type returned along the body. This created additional tests regarding downloading another type of text (html) and non-text (image).

Tell me if you need more on this particular function.

Related to #9

Note: to run with environment variables, use the following command: cargo run -- link1*link2*linkn where each link has the format https://website.com/file.xml

Each link is delimited by a * which can easily be changed if needed. I tried using ; but had some issues with it being read correctly. I've tested the code passing the same feed links from feeds.txt as env variables and the output matched the same as when using the feeds.txt file (cargo run is used).

This PR offers an alternative approach to #7.

While it is still interesting to read configuration from env vars, as suggested by the 12 Factors approach, we can easily move all files to a dedicated directory and rebind it when running the container. This is what this PR offers.

Assuming that the image is named rss2email:

• docker run rss2email runs the process with the default config, shipped in the image
• docker run -v path/to/config:/opt/rss2email/config rss2email runs the process with the config files located in path/to/config.

Bonus, you can also avoid shipping your credentials from the .env file in your Docker image.

I plan on diving deeper into this in a separate PR, but figured I could submit what I have now before it's too late to have this PR count towards Hacktoberfest!

It currently outputs the raw HTML to the console.

This PR contains a proposal of restyle for the documentation part, as per issue #21. I ended up preparing a practical example instead of exchanging generic guidance.
As before: its perfectly OK to discard this proposal as not-fitting.

This has been prepared taking consideration of the followings:

• Mature projects tend to touch all essential in README.md and provide link with details, your doc was already ahead on this.
• The environment variables sections covers 90% of the software usage, will be the first high step for users.

Some smaller/trivial matters

I used a README.md template that's commonly used.

Link to documentation are clearer when using the destination link title (or usage), like [how to build](#) instead of follow [this](#) for more details

Happy Hacktoberfest!

A couple things to note:

• I went with the blocking call as noted in the issue
• I didn't touch the existing async functions

Fixes #28

This has been sort of mentioned in #6 but since the issue is taking a long time I made a separate one.

Description

The post struct has a description field which is currently not present in the generated HTML.

A config parameter could be added for the preferred max length of a description.

Notes

Some feeds seem to be using a description tag instead of the official summary tag so might as well try and parse both.

The HTML output is generated by this function which currently does not include any CSS. Making some basic stylistic changes would be pretty cool.

Changes in the HTML itself are also welcome (such as including the post's description), the data you have available for each blog can be found here.

I don't have a very clear idea of what I'd want this to look like other than it being in dark mode, I like how Darkreader makes it look for instance. It would be nice to have a back-and-forth conversation about how this could look before you start implementing it!

Testing

Running cargo run should dump the generated HTML in the terminal which you can either save to a file and open in your browser or (if you are lazy like me) paste in something like https://html.onlineviewer.net/.

Edit: I might keep this open even after #37 is merged because I want to explore the idea of letting the user inject their own CSS through environment variables and/or predefined "themes".